On Mon, Dec 14, 2009 at 1:10 PM, Olemis Lang olemis@gmail.com wrote:
On Mon, Dec 14, 2009 at 3:46 PM, Nick Coghlan ncoghlan@gmail.com 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
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
If you're only concerned about 2.X, then yes, optparse will *never* be removed from 2.X. There will be a deprecation note in the 2.X documentation but deprecation warnings will only be issued when the -3 flag is specified. Please see the "Deprecation of optparse" section of the PEP:
http://www.python.org/dev/peps/pep-0389/#deprecation-of-optparse
Steve