Opster syntax in python 3 about opster HOT 3 CLOSED

Hm, in the end it probably would be nice to specify annotations, since in this case meaning of default values is not overloaded (which it is right now), so semantically that's cleaner. But I dislike the fact that default is going to be the last one here, it makes it harder to read code (in which case you don't usually need to read help).

Also, we can't restrict py3 to use only annotations - if you have application, which you want to work in both py2 and py3, you'll have to use current syntax.

In the end, maybe it's worth it to postpone implementation a bit. I'm not sure what's the situation globally, but I don't see anyone around me to work with python 3. :)

from opster.

No, it's not time for opster to drop support for python 2.x now. But some time in the future it will be, and opster will have the opportunity to require a single cleaner syntax. And, at that time anyone still wanting to support opster on 2.x and 3.x can just use an older version of opster, since the current versions won't support python 2.x anyway.

If there is a new syntax then opster can support both, perhaps by checking for keyword arguments and/or annotations. Anyone using those features must be using only python 3.x and should really be using opster's new, future syntax (whatever that is).

What I'm saying is that it would be good to make a decision on future syntax now because noone is using python 3.x yet.
So now, while noone's using it, is a good time to decide on a future syntax, implement/test it and display it prominently in the docs, so that anyone who starts something new in python 3.x will use it, and some of the people supporting both python 2.x and 3.x will be aware of the fact that the syntax will change at some point (they can always just embed an older version of opster if they need it to be eternally stable).

Also, I though of another possibility using annotations for positional arguments

@command()
def main(numtimes: (int, 'number of times'),
         inputfile: (file, 'file to read data from') = sys.stdin,
         *,
         format: ('f', 'output format') = 'binary',
         quiet:('q', 'Supress all output') = False):
     pass

Then opster could show help for the positional arguments and validate their types etc. This is posible with keyword-only arguments since opster has an independent way of distinguishing positional arguments and option arguments.

Also, since the main issue seems to be presentation, how about:

@opster.command()
def main(required_arg, optional_arg=None, *varargs,
         option1:('o', False, 'help for --option1') = False,
         option2:('O', 'default_cl', 'enter a value for option2') = 'default_py',
         option3:('q', 4, 'this will be a required kwarg when calling main()'),
         **globalopts)
    pass

This way it looks pretty much like before and you have the option to provide a different default value when main is called just as main(). With this form, if a default value for an option is not also provided at the end then keyword argument to main becomes a required keyword argument when main is called on its own. Alternatively, if desired, the functions kwdefaults can be modified in place so that they have the same default values as the options.

from opster.

Another syntax that has worked in all versions of opster although it's not really documented any more is

options = [('o', 'option1', False, 'help for option1')]

@opster.command(options=options)
def main(**opts):
    if opts['option1']:
        pass

The opster docs could describe that as a future-proof python 2.x and 3.x syntax.

from opster.