[Python-Dev] PEP 389: argparse - new command line parsing module (original) (raw)
Steven Bethard steven.bethard at gmail.com
Mon Sep 28 16:28:39 CEST 2009
- Previous message: [Python-Dev] PEP 389: argparse - new command line parsing module
- Next message: [Python-Dev] PEP 389: argparse - new command line parsing module
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Mon, Sep 28, 2009 at 6:03 AM, Jon Ribbens <jon+python-dev at unequivocal.co.uk> wrote:
On Mon, Sep 28, 2009 at 09:38:20AM +0100, Floris Bruynooghe wrote:
On Mon, Sep 28, 2009 at 06:59:45AM +0300, Yuvgoog Greenle wrote: > -1 for deprecating getopt. getopt is super-simple and especially useful for > c programmers learning python. > > +1 for argparse.+1 for eventual deprecation of optparse - optparse and > argparse have a very similar syntax and having both is just > confusing. tsboapooowtdi
+1 on all of this :-) It would be a shame to see getopt go but optparse -> argparse seems logical. +1 from me too - keep getopt, deprecate optparse.
Ok, sounds like there are a number of supporters for keeping getopt around and just deprecating optparse. For those who'd like to keep getopt around, I have a few questions:
Would you be opposed to a note in the getopt documentation suggesting argparse as an alternative?
Would you like argparse to grow an add_getopt_arguments method (as in my other post)?
If argparse grew an add_getopt_arguments, would you still want to keep getopt around? And if so, why?
Steve
Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus
- Previous message: [Python-Dev] PEP 389: argparse - new command line parsing module
- Next message: [Python-Dev] PEP 389: argparse - new command line parsing module
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]