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.

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.

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.

Hello,
attached a patch to add documentation about action=append and a default value.

Regards,
Sandro

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.)  :)

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

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.

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

> 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.

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?

É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.

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.

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 msg9944 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

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).

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