Implements GNU style scanning mode. The traditional
mode is used if the option string begins with + or if
the environment variable POSIXLY_CORRECT is set, just
like GNU getopt. 

Patch includes updated documentation and test. 

Logged In: YES 
user_id=6380

Rejected in this form.  We can't suddenly change the default
behavior.  If you want a way to support GNU style options
(which I personally hate, but which I would accept as an
option), try adding a different function (e.g.
gnu_getopt(...)) or add a flag argument (e.g. getopt(...,
gnu=1)).

Logged In: YES 
user_id=344921

The new patch uses a new function, gnu_getopt, instead of changing the default behaviour. 

Logged In: YES 
user_id=21627

The patch looks good to me. Since it introduces a new
feature,  it will be postponed after 2.2 (negotiate with the
2.2 release manager if you want to see it included).

Notice that it doesn't offer all features of GNU getopt. It
doesn't support the getopt_long_only mechanism (where all
options are long, even if they have a single - only).
Further, it doesn't allow the caller to specify ordering,
and it doesn't support the RETURN_IN_ORDER option (which
would be difficult to support with the current calling
convention, though).

I'm not asking that these problems are somehow resolved;
they are meant as proposals for improvements only.

Logged In: YES 
user_id=3066

The documentation needs to clearly describe the differences
between GNU-style scanning and what's done in
getopt.getopt() -- it seems to assume the reader knows the
differences.

The implementation of gnu_getopt() also assumes that args
will be non-empty.  If the caller wants only long options
and passes '' as args, IndexError will be raised.  Check for
a leading '+' with args.startswith('+') to be safe.

Logged In: YES 
user_id=21627

If there is no update of this patch by June 1, it will be
rejected.

Logged In: YES 
user_id=344921

New patch added, which hopefully fixes the identified problems. 

Logged In: YES 
user_id=21627

Any comments on
http://mail.python.org/pipermail/python-dev/2002-June/025002.html
?

Logged In: YES 
user_id=344921

The intent is to provide a function that works like GNU getopt. 
However, I don't think it's necessary that getopt.gnu_getopt works 
exactly as GNU getopt. If later GNU version introduces new features 
etc some time in the future, we can discuss if we want to add them 
or not when that happens. 

So, the name gnu_getopt is good enough I think. I won't object to an 
capitalized version either, but the current name is my preferred 
choice. 

Logged In: YES 
user_id=33168

Martin, didn't you check this in Lib/getopt.py 1.18?
Should this be closed?

Logged In: YES 
user_id=21627

Yes, I did, and I was pretty sure I closed this bug. Trying
again.

Thanks again for the patch.