Steven Bethard wrote:
On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang email@example.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).