The attached script demonstrates the bug.

option.dest should be set, even if not explicitly supplied in the call
to parser.add_option, by the time the callback is called.

Unless dest='something' is specified in the call to add_option, you will
get the following error when running "python test.py --myopt":

  File "test.py", line 4, in mycallback
    setattr(parser.values,option.dest,value)
TypeError: attribute name must be string

...as options.dest is still None.

I would expect options.dest to be computed as per the algorithm in
optparse.Option._check_dest.

Since you've done so much work debugging this, would you mind submitting
a patch, including a unit test that confirms the desired behavior?

I'm not sure I fully understand where the fix should go but I'll put a
note in to look into this.

In the meantime, a good workaround is to supply an explicit destination:

parser.add_option('--myopt',action='callback',callback=mycallback,dest='myopt')

I have never used callbacks but went through the docs/code and I am not
sure if there is a bug here. 

_check_dest() creates 'dest' only if 'type' is specified for the
'callback' option. With callbacks, it can not guess the type as there is
no 'store' action. The document does say that without 'type', optparse
does not know how many arguments to consume. I added 'type' to your
example add_option() and all is well. 

Please correct me if I am missing some thing here.

But what type should I specify?

I was using a callback to get a datetime object as an option...

>
> But what type should I specify?
>
> I was using a callback to get a datetime object as an option...
>

If you are looking for a new type of option than what are already
supported (string, int, long, choice, float and complex), you need to
extend optparse (there is a section for that). I personally prefer a
simple approach where the option value is taken as a string and any
processing is done on the value to convert to what ever type of object
one wants. For example, in this case, you can convert a string, say,
2007-10-8, internally to a datetime object.

Ping? I was hoping for a patch?

I was under the impression that no change is necessary but I will take a
closer look and will see if something needs to be done.

Hm, perhaps I misinterpreted the discussion. If no patch is necessary,
please close as won't fix or invalid.

> Hm, perhaps I misinterpreted the discussion. If no patch is necessary,
> please close as won't fix or invalid.

I spent some time looking at optparse code and OP's request.
_check_dest has a clear comment that says "dest" will be set iff a
"store" action is selected (which callback is not) or if a "type" is
given. But from the code itself, I don't see how setting "dest" in all
cases would be bad. Do you want to assign this to Greg Ward to ask his
opinion? Also, it doesn't look like we can directly patch optparse.py
as it seems to be auto-generated. On a side note, I don't have tracker
permissions to change status.

FWIW, the change to _check_dest to always set 'dest' breaks quite a few
tests.

Then let's leave well enough alone.  I believe Greg Ward doesn't usually
respond to queries about optparse, but I'm assigning it to him anyway in
case his interest is piqued.  But for now, let's close this.