[Python-Dev] PEP 389: argparse - new command line parsing module

[Glenn Linderman]

On approximately 9/29/2009 1:57 PM, came the following characters from 
the keyboard of Steven Bethard:
> On Tue, Sep 29, 2009 at 1:31 PM, Paul Moore <p.f.moore at gmail.com> wrote:
>> 2009/9/28 Yuvgoog Greenle <ubershmekel at gmail.com>:
>>> 1. There is no chance of the script killing itself. In argparse and optparse
>>> exit() is called on every parsing error (btw because of this it sucks to
>>> debug parse_args in an interpreter).
>> That one does worry me. I'd rather argparse (or any library function)
>> didn't call sys.exit on my behalf - it should raise an exception. Is
>> it actually true that argparse exits? (I can imagine that it might if
>> --help was specified, for example. An exception may not be right here,
>> but I still don't like the idea of a straight exit - I've used too
>> many C libraries that think they know when I want to exit).
> 
> This is behavior that argparse inherits from optparse, but I believe
> it's still what 99.9% of users want.  If you're writing a command line
> interface, you don't want a stack trace when there's an error message
> (which is what you'd get if argparse just raised exceptions) you want
> an exit with an error code. That's what command line applications are
> supposed to do.
> 
> If you're not using argparse to write command line applications, then
> I don't feel bad if you have to do a tiny bit of extra work to take
> care of that use case. In this particular situation, all you have to
> do is subclass ArgumentParser and override exit() to do whatever you
> think it should do.
> 
>>> 2. There is no chance the parser will print things I don't want it to print.
>> That may also be bad - for example, Windows GUI-mode programs raise an
>> error if they write to stdout/stderr. I could imagine using argparse
>> for such a program, and wanting to do something with --help other than
>> write to stdout and exit (a message box, for example). And yet, I'd
>> want access to the text argparse would otherwise write to stdout.
> 
> There is only a single method in argparse that prints things,
> _print_message(). So if you want it to do something else, you can
> simply override it in a subclass. I can make that method public if
> this is a common use case.


Documenting both of these options would forestall people from thinking 
it is only useful for console applications.  An example of using 
argparse with Tk (I think that is the only GUI that ships with Python) 
would also be good.  In making the method public you might want to 
rename it to something other than print_message.  If all the messages 
are errors, including "error" in the name would be good.  If not, 
classifying the errors vs non-errors as an extra parameter might be good 
(in other words... inform the user and continue, or inform the user and 
exit).  Separating the message from the classification is not good, 
because that leads to dialog boxes having only an "OK" button, and 
depending on the message, it can be really inappropriate to display an 
"OK" button... buttons named "Sorry", "Alas!", and "Exit" or "Quit" are 
often more appropriate, even when there is no user choice possible.

Clearly if someone is writing a GUI, they are willing to write lots of 
lines of code to do things... a couple more well-documented lines to 
integrate argparse into their chosen GUI doesn't seem onerous. 
Especially if they can cut, paste, and hack from the above-suggested 
example code, like they do for the rest of their GUI code.

Well, at least, cut, paste, and hack is how I write GUIs when I bother.

-- 
Glenn -- http://nevcal.com/
===========================
A protocol is complete when there is nothing left to remove.
-- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking