<div dir="ltr">+1 for deprecating optparse or at the very least building a timeline for it's deprecation. Don't say no to progress, just say when.<div><br></div><div>I just wrote pyopt <a href="http://code.google.com/p/pyopt/">http://code.google.com/p/pyopt/</a> because I think exposing functions to the command line is way too hard.</div>
<div><br></div><div>If Steven Bethard and the argparse community agree, I would really appreciate a convenience method named "add_function" built into the ArgumentParser. add_function would automagically read the docstring and understand what are the arguments for a given function. I'm willing and motivated to do the work for this. Annotations-type-casting could be awesome as well, but I'm not greedy enough to ask.</div>
<div><br></div><div>--MrPyopt</div><div><br><br><div class="gmail_quote">On Fri, Sep 11, 2009 at 12:39 AM, Michael Foord <span dir="ltr"><<a href="mailto:michael@voidspace.org.uk">michael@voidspace.org.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div></div><div class="h5">M.-A. Lemburg wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Michael Foord wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Antoine Pitrou wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Upfront people need to realize that we might have three argument<br>
parsing libraries for a while, but it won't be forever. If we get<br>
argparse accepted we would slowly deprecate at least optparse, if not<br>
getopt (lat time I tried to ditch getopt for Python 3 some argued that<br>
getopt supported stuff optparse didn't),<br>
<br>
</blockquote>
+0 on deprecating getopt, -1 on deprecating optparse. Breaking a<br>
perfectly functional and useful module is stupid.<br>
<br>
<br>
</blockquote>
So we're stuck with inferior technology?<br>
<br>
</blockquote>
<br>
If you have the choice between breaking backwards compatibility<br>
and downloading other implementations from PyPI, I think backwards<br>
compatibility counts more.<br>
<br>
We've just had a major change in the stdlib for 3.x. Then the 3.0<br>
release was ditched due to poor performance. If we now start<br>
deprecating widely used modules in 3.2, we're going to lose<br>
a major pro argument for using Python: that of a stable eco system<br>
to write code for.<br>
<br>
I don't think we should deprecate any commonly used module (in the<br>
3.x branch) unless there's a clear and documented migration path<br>
or -even better- a migration wrapper available for the deprecated<br>
module.<br>
<br>
The next major round of refactoring will have to wait for<br>
Python 4.x.<br>
<br>
<br>
</blockquote></div></div>
Language refactoring can wait for 4.0. Library improvements should be ongoing.<br>
<br>
As Brett says, even if we go down this road, optparse won't actually be removed for several years.<br><font color="#888888">
<br>
Michael</font><div class="im"><br>
<br>
-- <br>
<a href="http://www.ironpythoninaction.com/" target="_blank">http://www.ironpythoninaction.com/</a><br>
<a href="http://www.voidspace.org.uk/blog" target="_blank">http://www.voidspace.org.uk/blog</a><br>
<br>
<br>
_______________________________________________<br></div><div><div></div><div class="h5">
stdlib-sig mailing list<br>
<a href="mailto:stdlib-sig@python.org" target="_blank">stdlib-sig@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/stdlib-sig" target="_blank">http://mail.python.org/mailman/listinfo/stdlib-sig</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Yuv<br><a href="http://code.google.com/p/pyopt/">http://code.google.com/p/pyopt/</a><br>
</div></div>