[issue1243] option.dest not set when callback called with optparse

Guido van Rossum added the comment: 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. -- assignee: -> gward nosy: +gward resolutio

[issue1243] option.dest not set when callback called with optparse

Raghuram Devarakonda added the comment: FWIW, the change to _check_dest to always set 'dest' breaks quite a few tests. __ Tracker <[EMAIL PROTECTED]> __

[issue1243] option.dest not set when callback called with optparse

Raghuram Devarakonda added the comment: > 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

[issue1243] option.dest not set when callback called with optparse

Guido van Rossum added the comment: Hm, perhaps I misinterpreted the discussion. If no patch is necessary, please close as won't fix or invalid. __ Tracker <[EMAIL PROTECTED]> __ __

[issue1243] option.dest not set when callback called with optparse

Raghuram Devarakonda added the comment: 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. __ Tracker <[EMAIL PROTECTED]> _

[issue1243] option.dest not set when callback called with optparse

Guido van Rossum added the comment: Ping? I was hoping for a patch? __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue1243] option.dest not set when callback called with optparse

Changes by Christian Heimes: -- priority: -> normal versions: -Python 2.3, Python 2.4 __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list m

[issue1243] option.dest not set when callback called with optparse

Raghuram Devarakonda added the comment: > > 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 optpars

[issue1243] option.dest not set when callback called with optparse

Chris Withers added the comment: But what type should I specify? I was using a callback to get a datetime object as an option... __ Tracker <[EMAIL PROTECTED]> __ _

[issue1243] option.dest not set when callback called with optparse

Raghuram Devarakonda added the comment: 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' actio

[issue1243] option.dest not set when callback called with optparse

Chris Withers added the comment: 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') __

[issue1243] option.dest not set when callback called with optparse

Guido van Rossum added the comment: Since you've done so much work debugging this, would you mind submitting a patch, including a unit test that confirms the desired behavior? -- nosy: +gvanrossum __ Tracker <[EMAIL PROTECTED]>

[issue1243] option.dest not set when callback called with optparse

New submission from Chris Withers: 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 followin