On Mon, Dec 14, 2009 at 1:10 PM, Olemis Lang <ole...@gmail.com> wrote: > On Mon, Dec 14, 2009 at 3:46 PM, Nick Coghlan <ncogh...@gmail.com> wrote: >>> On Mon, Dec 14, 2009 at 11:12 AM, Olemis Lang <ole...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
