On Mon, Dec 14, 2009 at 3:46 PM, Nick Coghlan ncoghlan@gmail.com wrote:
Steven Bethard wrote:
On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang olemis@gmail.com wrote:
I thought that one of the following approaches would be considered :
1 - let optparse remain in stdlib (as is or not ...) 2 - 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.
[...]
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,
So, I don't get it . What's the difference between this and the first option I mentioned above ? I am probably missing the obvious but if optparse will be «never deprecated in 2.x» then what's gonna happen ? The only options I see are mentioned above (and I thought it was the first one ;o) :
- If (1) is the right one then -0 for considering backwards compatibility - If (2) is the right one then IMO, +1 for adding «further backwards compatibility cruft» in a separate module and remove it in Python 3.5