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

[Ian Bicking]

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.


-- 
Ian Bicking  |  http://blog.ianbicking.org  |  http://topplabs.org/civichacker