This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author bethard
Recipients andersk, bethard, drm, eric.araujo, eric.smith, gdb, nelhage, r.david.murray
Date 2011-02-06.22:01:26
SpamBayes Score 4.389935e-10
Marked as misclassified No
Message-id <1297029688.34.0.0273217553219.issue9334@psf.upfronthosting.co.za>
In-reply-to
Content
I don't think there's any sense in "un-deprecating" optparse because:

(1) It's only deprecated in the documentation - there is absolutely nothing in the code to keep you from continuing to use it, and there are no plans to remove it from Python.

(2) One (mis?)feature doesn't make the rest of the module useless.

And yes Eric, it would be awesome if you could develop a patch that allows the alternate parsing to be enabled when someone wants it. We should think about deprecation strategy though. Maybe something like:

== Python 3.3 ==
# Python 3.2 behavior
parser = ArgumentParser(error_on_unknown_options=True)
# proposed behavior
parser = ArgumentParser(error_on_unknown_options=False)
# deprecation warning when not specified
parser = ArgumentParser()

== Python 2.4 ==
# error warning when not specified
parser = ArgumentParser()

== Python 2.5 ==
# defaults to error_on_unknown_options=False
parser = ArgumentParser()

I'm not sure that's the right way to do it, but if the plan is to change the default at some point, we should make sure that we have a deprecation plan before we add the feature.
History
Date User Action Args
2011-02-06 22:01:28bethardsetrecipients: + bethard, eric.smith, eric.araujo, r.david.murray, andersk, gdb, nelhage, drm
2011-02-06 22:01:28bethardsetmessageid: <1297029688.34.0.0273217553219.issue9334@psf.upfronthosting.co.za>
2011-02-06 22:01:26bethardlinkissue9334 messages
2011-02-06 22:01:26bethardcreate