Steven Bethard wrote: > On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang <olemis at gmail.com> wrote: >> I thought that one of the following approaches would be considered : >> >> - let optparse remain in stdlib (as is or not ...) >> - re-implement optparse (i.e. a module having the same name ;o) using >> argparse >> >> isn't it ? > > Please read the PEP if you haven't, particularly the "Why isn't the > functionality just being added to optparse?" section. I don't believe > it is sensible to re-implement all of optparse. What Ian Bicking is > proposing, I believe, is simpler -- adding a few aliases here and > there so that you don't have to rename so many things when you're > upgrading from optparse to argparse. > > For what it's worth, I'm still not sure it's a good idea, for exactly > the reason Ian points out - "having another class like OptionParser > also feels like backward compatibility cruft". People also need to remember the very conservative deprecation path for optparse proposed in the PEP - never deprecated in 2.x, and only a PendingDeprecationWarning in 3.x up until 3.4 (likely to happen some time in 2013). With that kind of slow deprecation path, adding further backwards compatibility cruft to argparse itself seems redundant - the name changes from option to argument were instituted for a reason (since the scope of argparse really is wider than that of optparse). Cheers, Nick. -- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia ---------------------------------------------------------------
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4