Steven Bethard wrote: > On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang <ole...@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 | ncogh...@gmail.com | Brisbane, Australia --------------------------------------------------------------- _______________________________________________ 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