Pyopt - an attempt at a pythonic optparse
I put some sweat into this one so I was hoping to see if you guys like it or have any ideas for improvement. http://code.google.com/p/pyopt/ Currently there are 2 modes of operation, 1. keyword command-line functions which create switches (-m, -r etc). 2. positional command-line functions which simply translate positional arguments from the command-line to a function. possibly in the future I'll implement a mixed keyword/positional arguments behaviour. At the moment annotations are mandatory for explicitness and here's an example usage: from pyopt import CmdPos from pyopt import parse_cmds @CmdPos 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__": parse_cmds() Notice 4 things: * an import * a decorator * a parse_cmds() * type-annotations for casting The following functionality is exposed: 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 13 2 arguments required, got only 1. Run with ? or -h for more help.
RunThePun <ubershmekel@gmail.com> writes:
I put some sweat into this one so I was hoping to see if you guys like it or have any ideas for improvement. http://code.google.com/p/pyopt/
Thanks for your work on this.
from pyopt import CmdPos from pyopt import parse_cmds
My main complaint at this point is the chosen names. Within Python code, I don't need to be reminded that I'm writing Python. The module names should not be ‘pyopt’; you should choose a namespace that better describes what the module is for, without the ‘py’. Also, please name the classes and functions so they're not needlessly CprsdWrds. Instead, choose names that contain whole words, or at least very-commonly-used abbreviations with little ambiguity. That way the names will be both more descriptive and easier to pronounce, and thus easier to remember correctly. -- \ “[I]t is impossible for anyone to begin to learn that which he | `\ thinks he already knows.” —Epictetus, _Discourses_ | _o__) | Ben Finney
How about these names for the module:1. optionparse 2. shlopt (for shell options, sounds kinda cute albeit less descriptive) 3. shelloptions 4. ? And the decorator Names: 1. shell_expose_kwargs and shell_expose_args 2. expose_keywords and expose_arguments 3. expose and expose_keywords? 4. ? On Sun, Sep 6, 2009 at 4:59 AM, Ben Finney <ben+python@benfinney.id.au<ben%2Bpython@benfinney.id.au>
wrote:
RunThePun <ubershmekel@gmail.com> writes:
I put some sweat into this one so I was hoping to see if you guys like it or have any ideas for improvement. http://code.google.com/p/pyopt/
Thanks for your work on this.
from pyopt import CmdPos from pyopt import parse_cmds
My main complaint at this point is the chosen names.
Within Python code, I don't need to be reminded that I'm writing Python. The module names should not be ‘pyopt’; you should choose a namespace that better describes what the module is for, without the ‘py’.
Also, please name the classes and functions so they're not needlessly CprsdWrds. Instead, choose names that contain whole words, or at least very-commonly-used abbreviations with little ambiguity. That way the names will be both more descriptive and easier to pronounce, and thus easier to remember correctly.
-- \ “[I]t is impossible for anyone to begin to learn that which he | `\ thinks he already knows.” —Epictetus, _Discourses_ | _o__) | Ben Finney
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- Yuv hzk.co.il
On 09/06/2009 01:34 AM, Yuvgoog Greenle wrote:
How about these names for the module: 1. optionparse 2. shlopt (for shell options, sounds kinda cute albeit less descriptive)
It shouldn't really IMHO be called anything having to do with "opt" because that typically means the "-" (or in Windows "/") options (as in "getopt" and "optik" which is now "optparse"). Maybe "shellargs" or "argparse"? I think this is a really good start, thanks. Sean -- Sean Reifschneider, Member of Technical Staff <jafo@tummy.com> tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability
On Sun, 6 Sep 2009 06:14:00 pm Sean Reifschneider wrote:
On 09/06/2009 01:34 AM, Yuvgoog Greenle wrote:
How about these names for the module: 1. optionparse 2. shlopt (for shell options, sounds kinda cute albeit less descriptive)
It shouldn't really IMHO be called anything having to do with "opt" because that typically means the "-" (or in Windows "/") options (as in "getopt" and "optik" which is now "optparse").
But handling the dash command line options is exactly what the module is about. Perhaps the author can explain why this module is better or more pythonic than the two existing solutions already in the standard library. More importantly, while I'm sure the author is excited by his project, why has it been announced on this list? It seems to be off-topic to my mind. -- Steven D'Aprano
On 09/06/2009 02:21 AM, Steven D'Aprano wrote:
But handling the dash command line options is exactly what the module is about.
The example at the referenced page looks like it's all about handling non-option arguments. I must be missing something. Sean -- Sean Reifschneider, Member of Technical Staff <jafo@tummy.com> tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability
Currently the module handles positional arguments with one decorator and keyword arguments (with '-' switches) using another decorator. Maybe I should have linked to this more complete examples page: http://code.google.com/p/pyopt/wiki/Examples Steven: Forgive me, I am new to this list and now after checking I'm guessing you mean "stdlib-sig" is more fitting. So I'll move this discussion there. Just to clarify why I feel getopt/optparse aren't as pythonic - to me they feel clunky in that I need alot of ultra-explicit, extra-long lines to do some very basic things. The python I'm used to allows me to use open('filename').read() with reasonable default parameters. Now that I think of it, actually wrapping optparse might have been an easier implementation route for some of the functionality... Yuv On Sun, Sep 6, 2009 at 10:39 PM, Sean Reifschneider <jafo@tummy.com> wrote:
On 09/06/2009 02:21 AM, Steven D'Aprano wrote:
But handling the dash command line options is exactly what the module is about.
The example at the referenced page looks like it's all about handling non-option arguments. I must be missing something.
Sean -- Sean Reifschneider, Member of Technical Staff <jafo@tummy.com> tummy.com, ltd. - Linux Consulting since 1995: Ask me about High Availability
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- Yuv hzk.co.il
Yuvgoog Greenle wrote:
Just to clarify why I feel getopt/optparse aren't as pythonic - to me they feel clunky in that I need alot of ultra-explicit, extra-long lines to do some very basic things. The python I'm used to allows me to use open('filename').read() with reasonable default parameters. Now that I think of it, actually wrapping optparse might have been an easier implementation route for some of the functionality...
Something to think about is the possibility of redesigning your API proposal to function as a convenience wrapper around the existing optparse implementation. Convenience wrappers have a much lower hurdle to clear than complete alternative APIs (since the full power of the original API remains available by dropping back to the lower level). It's still no guarantee of course - there still needs to be a python-ideas (and then python-dev) consensus that the proposed wrappers actually are an improvement. There are definitely some things about the basic concepts behind your API that bother me as it currently stands: 1. One of the major features of optparse is that it encourages a data driven approach to option definition. Going back to a largely procedural approach as in your examples is not a step forward. 2. The use of a single global parser is a fairly questionable feature. 3. Losing the options object makes it more difficult to pass options around to code that may only care about some of the options A potentially valuable addition to optparse might just focus on your "CmdPos" idea and add the ability to add commands to the option parser: import optparse parser = optparse.parser() @parser.add_command def main(options, *args): """Command line help info goes here""" # Main body goes here # Adding more than one command would result in the first argument # being used to select between them by name as with CmdPos if __name__ == "__main__": parser.run_command() The other thing I find somewhat tedious with optparse is having to do lots of procedural checking of option constraints in order to provide helpful error messages. Being able to add independent constraint checks would help a great deal with that: @parser.add_constraint def check_args(parser, options, *args): if len(args) != 2: parser.error("Exactly 2 arguments required") Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
What do you think of the name "optionize" for the module then? @optionize.positional @optionize.keyword or maybe @optionize.args @optionize.kwargs On Mon, Sep 7, 2009 at 3:32 AM, Greg Ewing <greg.ewing@canterbury.ac.nz>wrote:
Sean Reifschneider wrote:
Maybe "shellargs" or "argparse"?
I don't think it should have "shell" in it, because the module doesn't really have anything to do with the shell. The shell is not the only way of launching a program and passing args to it.
-- Greg
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- Yuv hzk.co.il
Maybe opthandler? optparse2? Of course, not worth letting naming get in the way of progress...
Greg Ewing wrote:
Sean Reifschneider wrote:
Maybe "shellargs" or "argparse"?
I don't think it should have "shell" in it, because the module doesn't really have anything to do with the shell. The shell is not the only way of launching a program and passing args to it.
And the name "argparse" is already used by a popular package: http://code.google.com/p/argparse/
Eric Smith <eric@trueblade.com> writes:
And the name "argparse" is already used by a popular package: http://code.google.com/p/argparse/
Which raises the question: Would the original poster do the free software community a service by, instead of writing a new library from scratch, try improving to the existing libraries that are already in use? -- \ “As we enjoy great advantages from the inventions of others, we | `\ should be glad to serve others by any invention of ours; and | _o__) this we should do freely and generously.” —Benjamin Franklin | Ben Finney
To me the most awesome goal for this project would be to make it into the standard library. The concept is to allow a minimal-syntax decorator to expose regular functions as opposed to building an entire function just for parsing all the options. I don't mind where I implement this. =D On Mon, Sep 7, 2009 at 6:05 AM, Ben Finney <ben+python@benfinney.id.au<ben%2Bpython@benfinney.id.au>
wrote:
Eric Smith <eric@trueblade.com> writes:
And the name "argparse" is already used by a popular package: http://code.google.com/p/argparse/
Which raises the question: Would the original poster do the free software community a service by, instead of writing a new library from scratch, try improving to the existing libraries that are already in use?
-- \ “As we enjoy great advantages from the inventions of others, we | `\ should be glad to serve others by any invention of ours; and | _o__) this we should do freely and generously.” —Benjamin Franklin | Ben Finney
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
-- Yuv hzk.co.il
participants (10)
-
Antoine Pitrou -
Ben Finney -
Eric Smith -
Greg Ewing -
Nick Coghlan -
RunThePun -
Sean Reifschneider -
Steven D'Aprano -
Tennessee Leeuwenburg -
Yuvgoog Greenle