[Python-Dev] Pronouncement on PEP 389: argparse? (original) (raw)

Steven Bethard steven.bethard at gmail.com
Mon Dec 14 23:37:43 CET 2009

On Mon, Dec 14, 2009 at 1:10 PM, Olemis Lang <olemis at gmail.com> wrote:

On Mon, Dec 14, 2009 at 3:46 PM, Nick Coghlan <ncoghlan at gmail.com> 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 :  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

Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus

More information about the Python-Dev mailing list