[Python-Dev] Pronouncement on PEP 389: argparse?

[Neal Becker]

Ian Bicking wrote:

> On Mon, Dec 14, 2009 at 6:34 PM, ssteinerX at gmail.com
> <ssteinerx at gmail.com> wrote:
>>> Although I am of the people who think working modules shouldn't be
>>> deprecated, I also don't think adding compatibility aliases is a good
>>> idea. They only make the APIs more bloated and maintenance more tedious.
>>> Let's keep the new APIs clean of any unnecessary baggage.
>>
>> Agreed.  If you want to make an "adapter" to do things like convert 'int'
>> to int, then call the new API then fine, but don't start crufting up a
>> new API to make it 'easier' to convert.
>>
>> All crufting it up does is make it _less_ clear how to use the new API by
>> bring along things that don't belong in it.
> 
> The "new" API is almost exactly like the old optparse API.  It's not
> like it's some shining jewel of perfection that would be tainted by
> somehow being similar to optparse when it's almost exactly like
> optparse already.
> 
> If it wasn't like optparse, then fine, whatever; but it *is* like
> optparse, so these differences feel unnecessary.  Converting 'int' to
> int internally in argparse is hardly difficult or unclear.
> 
> If argparse doesn't do this, then I think at least it should give good
> error messages for all cases where these optparse-isms remain.  For
> instance, now if you include %prog in your usage you get: ValueError:
> unsupported format character 'p' (0x70) at index 1 -- that's simply a
> bad error message.  Giving a proper error message takes about as much
> code as making %prog work.  I don't feel strongly that one is better
> than the other, but at least one of those should be done.
> 
> 

I agree (and I've used both for quite a long time).  argparse has an api 
that is almost compatible with optparse in many common cases, but just 
renamed some things.