You may be interested in a little Python module I wrote to make handling of command line arguments even easier (open source and free to use) - http://freshmeat.net/projects/commando
> On Tuesday, January 11, 2011 12:18 AM Sohail wrote: > Hey, every body has their own favorite method/ways to process command line > arguments. I have worked on a little CPython extension to handle command line > arguments may be you will find it interesting and useful.... > > To download the source code.... > http://www.stupidcomputing.com/page.php?id=argsv > > Thank you. >> On Tuesday, January 11, 2011 2:25 AM Alice_Bevan?McGregor wrote: >> On 2011-01-10 21:18:41 -0800, Sohail said: >> >> >> Even I have implemented my own way to handle command-line scripts, >> marrow.script: >> >> https://github.com/pulp/marrow.script >> >> The idea with mine that you write a Python function... and that is it. >> The latest version has experimental support for class-based >> "subcommand" dispatch, but it needs work, needs to be updated to >> support sub-sub commands, and the help text generator needs to be >> overhauled to support classes properly. >> >> The argument list, typecasting, etc. is built from the argspec. Help >> text is pulled from the docstring. Decorators are provided to override >> short names, define explicit callbacks or typecasting functions, etc. >> >> I got tired of using PasteScript and OptParse. Mostly OptParse, actually. >> :/ >> >> - Alice. >>> On Tuesday, January 11, 2011 3:32 AM Michele Simionato wrote: >>> explicit callbacks or typecasting functions, etc. >>> ly. =A0:/ >>> >>> >>> it is a pity that the argument parsing modules in the standard library >>> are so verbose that everybody is reinventing the same thing :-( It >>> looks like you have reinvented plac: http://pypi.python.org/pypi/plac >>>> On Tuesday, January 11, 2011 9:37 AM Alice_Bevan?McGregor wrote: >>>> On 2011-01-11 00:32:32 -0800, Michele Simionato said: >>>> >>>> And a package called `commandline`. There are many command line >>>> parsing modules, many of which are unmaintained, few have reached 1.0. >>>> >>>> My criteria for 1.0? 100% unit test coverage, complete documentation, >>>> compatibility with 2.6+ and 3.1+ within a single package. >>>> marrow.script meets that criteria, do the others? :) >>>> >>>> - Alice. >>>>> On Tuesday, January 11, 2011 10:06 AM Alice_Bevan?McGregor wrote: >>>>> On 2011-01-11 00:32:32 -0800, Michele Simionato said: >>>>> >>>>> After looking into it, Plac's default help display is not very helpful; >>>>> you need to massage your application a fair amount before generating >>>>> nice, complete-looking argument lists and such. For example: >>>>> >>>>> def main(verbose: ('prints more info', 'flag', 'v'), dsn: 'connection >>>>> string'): >>>>> >>>>> @annotate(dsn="connection string", verbose="prints more info") >>>>> def main(dsn, verbose=False): >>>>> >>>>> The latter is marrow.script, and even without the annotation a more >>>>> complete help text is generated. The -v and flag nature are assumed >>>>> from the first unique character and default value. (Flags, when >>>>> present on the command line, invert the default value.) Py3k >>>>> annotations have not been implemented yet, though. >>>>> >>>>> Also included is an easy way to simulte command-line execution (i.e. by >>>>> reading arguments passed by hand and by returning the exit code, vs. >>>>> reading sys.argv and calling sys.exit()) for unit testing purposes. >>>>> Plac appears (from the documentation) to be written on top of argparse. >>>>> >>>>> - Alice. >>>>>> On Tuesday, January 11, 2011 10:49 AM Michele Simionato wrote: >>>>>> And the problem with that being what? >>>>>>> On Tuesday, January 11, 2011 11:22 AM Jean-Michel Pichavant wrote: >>>>>>> Michele Simionato wrote: >>>>>>> ... not available to python 2.5 / 2.6 users :) >>>>>>> >>>>>>> JM >>>>>>>> On Tuesday, January 11, 2011 11:26 AM Michele Simionato wrote: >>>>>>>> wrote: >>>>>>>> . >>>>>>>> >>>>>>>> In that case easy_install/pip/whatever will install the dependency >>>>>>>> automatically (who is installing >>>>>>>> dependencies by hand nowadays?). More seriously I thought being based >>>>>>>> on a solid module which is >>>>>>>> also part of the standard library (for Python 2.7+) was an asset of >>>>>>>> plac. >>>>>>>>> On Tuesday, January 11, 2011 12:57 PM Mike wrote: >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> I do. Is this bad? :} >>>>>>>>>> On Wednesday, January 12, 2011 12:41 AM Michele Simionato wrote: >>>>>>>>>> 'connection >>>>>>>>>> re info") >>>>>>>>>> >>>>>>>>>> Honestly I do not see any significant difference both in the >>>>>>>>>> level of verbosity for the annotations and in the quality of the >>>>>>>>>> help >>>>>>>>>> message provided in the absence of annotations. Originally plac too >>>>>>>>>> was able to recognize flags automatically by looking at the default >>>>>>>>>> value (if the default value is a boolean then the option is a flag); >>>>>>>>>> however I removed that functionality because I wanted to be able to >>>>>>>>>> differentiate between flag and (smart) options (see >>>>>>>>>> http://micheles.googlecode.com/hg/plac/doc/plac.html#scripts-with-options-a= >>>>>>>>>> nd-smart-options). >>>>>>>>>>> On Wednesday, January 12, 2011 12:43 AM Michele Simionato wrote: >>>>>>>>>>> You are simply spending more time than needed, since there are >>>>>>>>>>> already >>>>>>>>>>> tools available to perform the task for you. >>>>>>>>>>>> On Wednesday, January 12, 2011 12:09 PM Alice_Bevan?McGregor wrote: >>>>>>>>>>>> On 2011-01-11 21:41:24 -0800, Michele Simionato said: >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Not >>>>>>>>>>>> entirely sure what you mean by 'smart' options. If your'e >>>>>>>>>>>> referring to >>>>>>>>>>>> using a single hyphen and a list of characters to represent a long >>>>>>>>>>>> option (which, to the rest of the world, use two leading hyphens) >>>>>>>>>>>> then >>>>>>>>>>>> that is pretty weird. ;) >>>>>>>>>>>> >>>>>>>>>>>> Consider most of the GNU tools: >>>>>>>>>>>> >>>>>>>>>>>> ls -lvh >>>>>>>>>>>> tar -xzvf file.tgz (goes so far as to make the leading hyphen >>>>>>>>>>>> optional!) >>>>>>>>>>>> less -ceF logfile >>>>>>>>>>>> bc -qw >>>>>>>>>>>> ps -aux (same as tar) >>>>>>>>>>>> >>>>>>>>>>>> And even third-party tools: >>>>>>>>>>>> >>>>>>>>>>>> mysql -fH >>>>>>>>>>>> pg_dump -abO ... >>>>>>>>>>>> >>>>>>>>>>>> One major system in the world that does not really differentiate >>>>>>>>>>>> between >>>>>>>>>>>> long and short options is... DOS, and by extension, Windows. But >>>>>>>>>>>> they >>>>>>>>>>>> also use / as a switch character. >>>>>>>>>>>> >>>>>>>>>>>> Anyway; I am happy with what I have wrought (and am continuing to >>>>>>>>>>>> update >>>>>>>>>>>> with support for class-based sub-command dispatch) and will be >>>>>>>>>>>> utilizing it for all scripts in the Marrow suite. To each their >>>>>>>>>>>> own, >>>>>>>>>>>> but reinvention itself can be for motivations other than NIH. I >>>>>>>>>>>> wanted >>>>>>>>>>>> something pure-Python, portable across the 3k barrier without code >>>>>>>>>>>> modification (no 2to3), that did not use optparse, getopt, or >>>>>>>>>>>> argparse >>>>>>>>>>>> and basically be a translation layer. It can be simpler than >>>>>>>>>>>> that, as >>>>>>>>>>>> marrow.script demonstrates. >>>>>>>>>>>> >>>>>>>>>>>> - Alice. >>>>>>>>>>>>> On Thursday, January 13, 2011 3:32 AM Michele Simionato wrote: >>>>>>>>>>>>> Yes, and plac (it is argparse actually) can accomodate >>>>>>>>>>>>> the Windows convention by setting the prefix_chars to "/". I >>>>>>>>>>>>> wanted to >>>>>>>>>>>>> be >>>>>>>>>>>>> able to give that freedom even if personally am more used to the >>>>>>>>>>>>> GNU >>>>>>>>>>>>> double-dash >>>>>>>>>>>>> convention. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> No arguing against that. BTW, I was not criticizing >>>>>>>>>>>>> marrow.script, I >>>>>>>>>>>>> was simply >>>>>>>>>>>>> deploring the situation in the standard library. If the same >>>>>>>>>>>>> approach >>>>>>>>>>>>> for parsing >>>>>>>>>>>>> command-line options is being reinvented by different people >>>>>>>>>>>>> multiple >>>>>>>>>>>>> times there >>>>>>>>>>>>> must be something wrong with the current standard. >>>>>>>>>>>>> Submitted via EggHeadCafe >>>>>>>>>>>>> SQL Server Best Practices >>>>>>>>>>>>> http://www.eggheadcafe.com/tutorials/aspnet/56efb426-550b-48cc-b52a-eca25b6cd427/sql-server-best-practices.aspx -- http://mail.python.org/mailman/listinfo/python-list
