Mailman 3 September 2009 - stdlib-sig

Re: [stdlib-sig] should we try to add argparse?
by Laura Creighton 11 Sep '09

11 Sep '09

In a message of Thu, 10 Sep 2009 18:11:21 EDT, Barry Warsaw writes: >Then we have a serious long term problem. Taken to its logical =20 >conclusion, we're going to end up with a batteries included standard =20 >library with nothing but old, /effectively/ obsolete APIs with all the =2 >0= > >good new stuff that people want in the Cheeseshop. Okay, in reality =20 >it will always be a mix, but I do think this policy means that the =20 >APIs in the stdlib will degrade and ultimately decay over time. > >If that's the case, why even have a stdlib? That is, actually, pretty much what I want a stdlib for. I don't want it to contain the newest, greatest, and best ways of doing things. I want it to contain the things that people are willing to maintain until hell freezes over, which will largely be things that aren't ever going to change until hell freezes over. I want users to know that if they want the latest, greatest, and best ways of doing things -- the way we recommend people do things now -- then they should not be assuming that the standard library has it. The point of using things in the standard library is so that you will have a reason to believe that if you write your code using this stuff, then you don't have to worry (much, at any rate, there is always Python 3.0) about having to change your code at some later date because the standard library now has a new way of doing things which some people like a lot better than the old way you used. Right now there are a whole lot of users of python programs who have no programming skills whatsoever. Waking up one morning and discovering that their computing environment has gone to hell because the default Python is now 3.7 and now the option parsing in their programs don't work any more -- and they will have to get a replacement from the original author of the tool, or some other programmer seems a remarkably uncivil way to treat your users. If new python programmers cannot be trusted to read the standard library manual and understand what a paragraph that says: XXX is included in the standard library for reasons of backwards compatibility. We strongly recommend that you use YYY instead. then they are too clueless to worry about. But if, having read this, they choose to use XXX anyway, as today many people use getopt instead optparse, when they are writing python programs that will only be deployed on windows and who want the /option syntax that optparse denies them, well then, that's their choice too. I don't know anything about argparse, but reading the docs leads me to believe it is a big improvement on optparse, which I dislike. But Simon Willison's optfunc http://simonwillison.net/2009/May/28/optfunc/ looks interesting to me as well, as would a parser that took its information from docstrings. There are two foolish attitudes here. The first is that being tidy, or impossible for newbies to misunderstand, because we won't give them the option of using the wrong stuff is a higher value than not breaking perfectly good working code. It's better to teach the newbies that there are lots of options out there than to hide this fact from them. The second foolish attitude is that nobody seems to be discussing 'do we like argparse enough to be willing to maintain it for the indefinite future as part of the standard library'. Because, to my mind, that is the real question. If we no longer care about that, and things in the standard library can be removed 'whenever we have a replacement that we like better', then the standard library is no longer really a _standard_ library, but rather a _stuff we suggest you use_ library. And do we really want one of those? I sure don't. Laura <snip> >-Barry

3 2

Pyopt - command-line options that are alot easier than optparse
by Yuvgoog Greenle 11 Sep '09

11 Sep '09

Hi stdlib-sig, I wanted to ease exposing functions to the command-line using python 3 features and the result is http://code.google.com/p/pyopt/ <http://code.google.com/p/pyopt/>I think this could be good stuff for the standard library and I'm not sure how to go about it, should I work on integrating with optparse/optik (is that project still active?) or should this be a separate module? This is an example usage of pyopt.0.71: --- import pyopt expose = pyopt.Exposer() @expose.args def possy(archer:str, boulder:float, magic:int=42): """Shows an example positional command-line function. archer - is a str boulder - should be a float magic - a number that is magical""" print(repr(archer), repr(boulder), repr(magic)) if __name__ == "__main__": expose.run() --- And this is what you get: C:\>example.py -h Usage: example.py archer boulder [magic] Shows an example positional command-line function. archer - is a str boulder - should be a float magic - a number that is magical C:\>example.py 1 2 3 '1' 2.0 3 C:\>example.py 1 2 '1' 2.0 42 C:\>example.py 5 2 arguments required, got only 1. Run with ? or -h for more help. --- For more examples and functionality (like multiple functions) look at: http://code.google.com/p/pyopt/wiki/Examples Notes: 1. I know the names aren't perfect (module pyopt, class Exposer and the decorator methods args/kwargs/mixed). Please reply if you have better names in mind. 2. I realize this isn't as flexible as optparse and passing options around multiple different sub-functions is harder. This module is strictly a quick and clean solution to a very day-to-day use case: bridging python functions to command-line. 3. Feedback would be greatly appreciated. I would like to know if I'm the only one who's tired of sys.argv/optparse boilerplate. -- Yuv

6 7

Re: [stdlib-sig] should we try to add argparse?
by Laura Creighton 11 Sep '09

11 Sep '09

In a message of Thu, 10 Sep 2009 19:55:42 -0300, Collin Winter writes: >Honest question, having only read the docs about argparse: would it be >possible to merge the functionality of argparse into optparse and so >preserve a greater measure of backwards compatibility? Some of the >stuff I'm reading about in >http://argparse.googlecode.com/svn/trunk/doc/argparse-vs-optparse.html >looks like it should be able to be integrated fairly easily into the >existing optparse structure. > >Collin Winter Having looked at the code for optparse, I would say, no, hacking the optparse enhancements into optparse would be extremely difficult. optparse was designed by somebody who finds certain common patterns of option parsing (required options, parsing options passed as /whatever) such a terrible idea that preventing people from doing these things, even if they -really-, -really-, wanted to was a significant design goal. Laura

1 0