[Python-Dev] Pronouncement on PEP 389: argparse?

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:


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

More information about the Python-Dev mailing list