msg80704 - (view) |
Author: Fons Dijkstra (pycurry) |
Date: 2009-01-28 10:58 |
Although it is possible to specify a default value for an append action, either directly or through the set_default() function, it is not handled correctly when this default is overruled by the user. Take for example the following code: import optparse parser = optparse.OptionParser() parser.add_option("-o", "--option", action = "append") parser.set_defaults(option = ["a"]) options, args = parser.parse_args() print options When this is called without arguments the following is printed: {'option': ['a']} # as expected But when it is called with for example with -ob the following is printed: {'option': ['a', 'b']} # expected {'option': ['b']} So the default option is also appended, even if the option is explicitly defined by the user. |
|
|
msg99443 - (view) |
Author: Andrew McNabb (amcnabb) |
Date: 2010-02-16 22:24 |
I think that optparse is doing the right thing here. I think that your code example should be changed to: import optparse parser = optparse.OptionParser() parser.add_option("-o", "--option", action = "append") options, args = parser.parse_args() if not options.option: options.option = ['a'] print options Think of the default as the initial list, and each time the -o option is specified, an item is appended to that initial list. |
|
|
msg99452 - (view) |
Author: R. David Murray (r.david.murray) *  |
Date: 2010-02-17 00:35 |
I agree with Andrew, but I think the optparse documentation should make it clear that this is what happens with a default value for an 'append' action. It is *implied* by the fact that append says it appends to a list, and default says the value is set before any options are parsed, but it should be made explicit in the docs for the 'append' action. Doc patch welcomed. |
|
|
msg117821 - (view) |
Author: Sandro Tosi (sandro.tosi) *  |
Date: 2010-10-01 18:18 |
Hello, attached a patch to add documentation about action=append and a default value. Regards, Sandro |
|
|
msg117836 - (view) |
Author: Éric Araujo (eric.araujo) *  |
Date: 2010-10-01 21:14 |
Thanks for the patch. Some remarks: > :attr:`~Option.dest` variable, that already contains the default value I would have used “which” here, but I’m not a native speaker. > not replaced (contrary to what one can think) I’d have used a comma, not parens. > This behaviour is clear “makes sense” sounds better to me. > think that with a default value :attr:`~Option.dest` is a list I suggest a comma after “value”. > any additional option is appended to that list s/option/value/ Let me use this reply to welcome you in the bug tracker. I hope you get warn fuzzy feelings when your patches are accepted or your comments acted upon. I’m also looking forward for a better Python-Debian relationship. (Cultural note: It’s not usual to say hello and regards in messages on this tracker. I did it too at first but was told it was unnecessary.) :) |
|
|
msg117973 - (view) |
Author: Sandro Tosi (sandro.tosi) *  |
Date: 2010-10-04 17:45 |
Hi Éric, thanks a lot for your review. Your comments are just fine, so I'm attaching a new patch that contains them. Yes, it's really nice to see one's work being accepted, and I do recognize I have a lot to learn about python procedures (either written or not :) so be sure I won't be demotivated by some initial "problems". About the Debian-Python relationship, I have absolutely no control over interpreters packages in Debian, but I do care so much about Python that I thought giving my hand here would be quite right (and who knows, maybe one day, I'll be a core developer too :) . Cheers, Sandro |
|
|
msg117977 - (view) |
Author: Éric Araujo (eric.araujo) *  |
Date: 2010-10-04 18:18 |
Forgot this one: > `appended` I don’t remember the default reST role being used in the Python docs; I don’t even remember what it is. Your example makes me suspect emphasis, so using *appended* would do the same thing and be explicit. > contrary to what one can think Still not a native speaker, but wouldn’t “may think” be more suited here? Apart from that, +1. |
|
|
msg117978 - (view) |
Author: Sandro Tosi (sandro.tosi) *  |
Date: 2010-10-04 18:26 |
On Mon, Oct 4, 2010 at 20:18, Éric Araujo <report@bugs.python.org> wrote: > Éric Araujo <merwok@netwok.org> added the comment: > > Forgot this one: > >> `appended` > I don’t remember the default reST role being used in the Python docs; I don’t even remember what it is. Your example makes me suspect emphasis, so using *appended* would do the same thing and be explicit. I think I looked in other part of the optparse.rst file how it's done and used that, but I'm fine either ways. >> contrary to what one can think > Still not a native speaker, but wouldn’t “may think” be more suited here? ah ok, it might me more correct, dunno (not native too) > Apart from that, +1. Thanks! but what should I do: prepare a new patch with this 2 quite little changes or leave that to the committer? Regards, Sandro |
|
|
msg117979 - (view) |
Author: Éric Araujo (eric.araujo) *  |
Date: 2010-10-04 18:37 |
> I think I looked in other part of the optparse.rst file how it's done and used that Alright, let’s leave it alone then. >>> contrary to what one can think >> Still not a native speaker, but wouldn’t “may think” be more suited here? >ah ok, it might me more correct, dunno (not native too) It has to do with the degree of probability you assign to the thought. Unless someone adds something, I’ll commit your patch in some days. I’ll change “can”, don’t bother doing another patch. |
|
|
msg122979 - (view) |
Author: Eli Bendersky (eli.bendersky) *  |
Date: 2010-12-01 03:52 |
I fuzzily recall there was somewhere a decision to use the American spelling of some words, like s/behaviour/behavior/ appearing in this patch. Is this right, or was it decided that it doesn't matter? |
|
|
msg122980 - (view) |
Author: Eli Bendersky (eli.bendersky) *  |
Date: 2010-12-01 03:55 |
Éric, also re your previous message, I personally would prefer seeing "contrary to what one can think" removed altogether. IMHO it's too chatty for an official document and doesn't really add new information over the sentence it follows. |
|
|
msg122985 - (view) |
Author: Raymond Hettinger (rhettinger) *  |
Date: 2010-12-01 05:33 |
Note, the :attr:`~Option.dest` variable is a list which includes default values if any are defined. Options on the command-line are appended to this list. Accordingly, the list may contain both the default value and the value passed on the command-line. |
|
|
msg168847 - (view) |
Author: Louis Deflandre (louis.deflandre) |
Date: 2012-08-22 07:37 |
Hello, Tell me if the issue is too old to deserve comments anymore. But I would like to challenge the conclusion made in this issue. The message stated "Think of the default as the initial list" but it is inconsistent with the proper meaning of default which can be defined as : "a preselected option adopted by a computer program or other mechanism WHEN NO ALTERNATIVE IS SPECIFIED" (http://www.wordreference.com/definition/default - Oxford Dictionary). The "initial list" conclusion seems to me more implementation oriented than really user oriented |
|
|
msg168889 - (view) |
Author: R. David Murray (r.david.murray) *  |
Date: 2012-08-22 14:53 |
It may or may not be too old to deserve comments, but it is too old to do anything about it. This can't change for backward compatibility reasons, and since optparse is deprecated in favor of argparse it isn't getting any new features. We still need to apply the doc patch, though...(makes note to self). |
|
|
msg170064 - (view) |
Author: Roundup Robot (python-dev)  |
Date: 2012-09-08 20:48 |
New changeset 8c60bb098eff by R David Murray in branch '3.2': #5088: document behavior of optparse defaults with 'append' action. http://hg.python.org/cpython/rev/8c60bb098eff New changeset 0c2bdd2c2032 by R David Murray in branch 'default': Merge #5088: document behavior of optparse defaults with 'append' action. http://hg.python.org/cpython/rev/0c2bdd2c2032 New changeset 79f6d4aff39d by R David Murray in branch '2.7': closes #5088: document behavior of optparse defaults with 'append' action. http://hg.python.org/cpython/rev/79f6d4aff39d |
|
|