pyopt-style annotations instead of @cmdln.option [moved]

[trentm]

This is Issue 19 moved from a Google Code project.
Added by 2009-09-09T17:10:56.000Z by Sridhar....@gmail.com.
Please review that bug for more context and additional comments, but update this bug.

Original labels: Type-Enhancement, Priority-Low, Usability

Original description

Starting with Python3, you can add 'annotations' to function arguments.

>>> def foo(a:int, b:"hello"): pass
... 
>>> foo.__annotations__
{'a': <class 'int'>, 'b': 'hello'}
>>>

A new optparser alternative called &quot;pyopt&quot; makes use of this feature to 
make writing optparser definitions in a seamless way: http://
code.google.com/p/pyopt/wiki/Examples

For example,

@expose.kwargs
def bigfun(brightness:int, nudge:bool, happy:bool, shaft:str='gold'):
    &quot;&quot;&quot;
    bigfun is a keyword command-line function.
    Switches can be given in any order.
    Also, booleans can be combined ie: -nh
    -b --brightness - how bright is it outside on a scale of 1-10
    -n --nudge - are you nudging me?
    -h --happy - script should be happy.
    -s --shaft - what kind of shaft are you?
    &quot;&quot;&quot;

That is there is to it. The option type and option default value are 
probably derived from the typed annotation (int, bool, str) while the 
short string and long string (-s, --brightness) including option help doc 
are automatically &quot;extracted&quot; from the docstring of the function. Me likes 
this.