Message128090
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. |
|
Date |
User |
Action |
Args |
2011-02-06 22:01:28 | bethard | set | recipients:
+ bethard, eric.smith, eric.araujo, r.david.murray, andersk, gdb, nelhage, drm |
2011-02-06 22:01:28 | bethard | set | messageid: <1297029688.34.0.0273217553219.issue9334@psf.upfronthosting.co.za> |
2011-02-06 22:01:26 | bethard | link | issue9334 messages |
2011-02-06 22:01:26 | bethard | create | |
|