Ian Bicking wrote: > On Mon, Dec 14, 2009 at 6:34 PM, sstein...@gmail.com > <sstein...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
