Ideas for a module to process command line arguments

Anjum Naseer eggheadcafe at anjum.otherinbox.com
Sun Feb 6 09:45:01 EST 2011 

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

More information about the Python-list mailing list