optparse "append" action should always make the em

[jemfinch]

BPO	819178
Nosy	@freddrake

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2004-05-05.01:42:10.000>
created_at = <Date 2003-10-07.10:47:00.000>
labels = ['type-feature']
title = 'optparse "append" action should always make the em'
updated_at = <Date 2004-05-05.01:42:10.000>
user = 'https://bugs.python.org/jemfinch'

bugs.python.org fields:

activity = <Date 2004-05-05.01:42:10.000>
actor = 'gward'
assignee = 'gward'
closed = True
closed_date = None
closer = None
components = ['None']
creation = <Date 2003-10-07.10:47:00.000>
creator = 'jemfinch'
dependencies = []
files = []
hgrepos = []
issue_num = 819178
keywords = []
message_count = 4.0
messages = ['54046', '54047', '54048', '54049']
nosy_count = 3.0
nosy_names = ['fdrake', 'gward', 'jemfinch']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = None
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue819178'
versions = []

[jemfinch]

I was torn between "Bug" and "RFE" on this one.

Anyway, with options whose action is "append",
optparse.OptionParser will set the option to None if
it's never called. Instead, I think it should set the
option to the empty list, so code can iterate over the
list regardless of whether the option was ever given.
It keeps users from having to guard their iteration
with "if options.foo:"

Such a change would be slightly backwards-incompatible;
users who use "if option.foo is None:" form instead of
just "if not options.foo:" would run into trouble, as
well as those users who used an "else" statement in
their loops. The latter seemed like a big problem,
until I realized that those users' code *already*
guards against the empty case, and thus shouldn't run
into difficulties.

[jemfinch]

Logged In: YES
user_id=99508

So, I *thought* I could change this to an RFE after
submitting it, but apparently not.

[freddrake]

Logged In: YES
user_id=3066

I'd agree that supplying [] as the default is the right
thing to do, but the compatibility issue pretty much kills
it. This should probably become a documentation issue; a
hint to use default=[] would go a long way, and works with
the existing code.

[gward]

Logged In: YES
user_id=14422

First of all, this should have been filed with the 'optik'
project, not Python. Oh well, no matter, because I'm going
to refuse it anyways.
Adding "default=[]" to the add_option() call is not such a
burden, and
Optik/optparse is mature enough that I don't want to break b/w
compatibility.