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

[Glenn Linderman]

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,
>>> _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.
> 
> 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