[ python-Feature Requests-819178 ] optparse "append" action should always make the em

SourceForge.net noreply at sourceforge.net
Tue May 4 22:01:33 EDT 2004


Feature Requests item #819178, was opened at 2003-10-07 05:47
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=819178&group_id=5470

Category: None
Group: None
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Jeremy Fincher (jemfinch)
>Assigned to: Greg Ward (gward)
Summary: optparse "append" action should always make the em

Initial Comment:
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.

----------------------------------------------------------------------

Comment By: Greg Ward (gward)
Date: 2004-05-04 20:42

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

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-04-01 03:16

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

----------------------------------------------------------------------

Comment By: Jeremy Fincher (jemfinch)
Date: 2003-10-07 05:48

Message:
Logged In: YES 
user_id=99508

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

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=819178&group_id=5470



More information about the Python-bugs-list mailing list