[Python-Dev] PEP 389: argparse - new command line parsing module (original) (raw)

Glenn Linderman v+python at g.nevcal.com
Wed Sep 30 01:59:22 CEST 2009

On approximately 9/29/2009 4:38 PM, came the following characters from the keyboard of Steven Bethard:

On Tue, Sep 29, 2009 at 3:04 PM, Glenn Linderman <v+python at g.nevcal.com> wrote:

On approximately 9/29/2009 1:57 PM, came the following characters from the keyboard of Steven Bethard:

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. [snip] There is only a single method in argparse that prints things, printmessage(). 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. I'm totally fine with people thinking it is only useful for console applications. That's what it's intended for. That said, if there are people out there who want to use it for other applications, I'm happy to make things easier for them if I know concretely what they want.

Hmm. Maybe that is partly why (sadly) so many GUI programs don't offer much in the way of command line options. Of course, many of their users in Windowsland wouldn't know how to tweak the shortcut to invoke them with options anyway, which might be another part. Fortunately, there are some good Windows programs that do offer rich GUIs and also rich command line options (e.g. IrfanView and ImgBurn)

An example of using argparse with Tk (I think that is the only GUI that ships with Python) would also be good. I don't really use GUI libraries, so I wouldn't be able to come up with such an example. I'd also rather not make API changes based on speculative use cases, so before I spend time documenting these things, I'd really like to hear from someone who has already, say, used getopt or optparse in conjunction with a GUI library, and what feedback they have about that.

I'm not a Tk user, just coming to Python from Perl, where I used Win32::GUI, but when I was looking for a functional and portable GUI development package, Perl didn't have one (still doesn't have one that supports Unicode and printing), and Python does... so here I come to Python and Qt. From my experience in Perl GUI Windowsland, the primary issue with command line parsing is displaying the message in a dialog instead of STDOUT. But the message and the user choices have to be known at the same time to design the dialog box. And, there is nothing so aggravating as to be shown an error message, and the only option is a button that says "OK", when it clearly isn't OK. So the tone/type of the messages also needs to be known, even when there are no user choices.

The --help option could display the help message, and offer OK.

Many errors (particularly unrecoverable ones) should display the error message, and offer an Exit button, or just the close box.

A few (although probably only highly customized user options) might want to give the user multiple recovery options.

So, I guess I'm in the unfortunate position of seeing the need, but not having used these specific technologies enough to offer an example either. So far, I've only used optparse (just now hearing about argparse in this thread) for command line programs in Python, and I am still just experimenting with Qt, and don't have enough familiarity with it yet to think that what I'm doing is best practices.

I think it would be sad to a new replacement for optparse that didn't GUI usage, though, at least in a limited form. The concepts I describe seem sufficient from experience in other environments, and I would think they would be sufficient in Python too, but I'm too new here to state that definitely.

-- Glenn -- http://nevcal.com/

A protocol is complete when there is nothing left to remove. -- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking

More information about the Python-Dev mailing list