The intent, design and plans for pyopt.

Positional/Keyword arguments

Currently these are the modes of operation:

1. args - A decorator for positional arguments.
2. kwargs - A decorator for keyword arguments.
3. mixed - A decorator which will allow both usages. This is probably what you'll usually use.

Dilemmas

Currently known compromises that are open to discussion:

1. This module was specifically designed with python 3 in mind, certain features can be converted to python 2.x, but the awesome ones can't.
2. Keyword command-line functions require every argument to start with a different letter to avoid collisions.
3. Booleans can't default to false. I couldn't think of a use case for this so tell me if you did.

Summary of feedback from python-ideas

1. The module name isn't perfect, the "py" in pyopt is good for pygame but not so good for lets say "pyurllib". Alternate names could be:
1. shlopt
2. optionize
3. opthandler
4. optparse/optparse2 - possibly just contributing the decorators to optik, if optik and the py-lists agree.
5. expose
6. Suggestions?
2. The decorator names are CprdWrds so these names might be better:
1. positional, keywords
2. args, kwargs
3. expose, expose_keywords
4. add_command, (hmm...)
5. Suggestions?
3. The internal global variables are a bad practice. The solution is to have whoever imports pyopt create an instance and use decorators associated with that instance.

What pyopt is or isn't

Nick Coghlan said on python-ideas:

One of the major features of optparse is that it encourages a data driven approach to option definition

and he also said:

Losing the options object makes it more difficult to pass options around to code that may only care about some of the options

I don't feel python needs another option organizer at all. If one needs to pass the same bulk of options around in multiple subfunctions - that's probably not for pyopt. I do believe python needs an easy to use, quick and clean solution for exposing functionality at "shell-point". I find myself way too many times hacking around with sys.argv just to avoid the long lines of optparse boilerplate. pyopt should be the easy way to call your functions from the command line. I'm going to have to think about some things:

• If I implement a mixed decorator that accepts -options as well as positional arguments, all the positional arguments can't start with a hyphen '-' (or at least the first one can't). Bummer.
• I'm leaning towards defaulting parameters that don't have an annotation to str. That way, you could just decorate a function and BOOM, new functionality, kinda awesome.
• The internal global variable thing is most worrying on occasions where a package that has many scripts (some of which use pyopt) all register their functions in the same place, which sucks. You'll get functions from all over, when all you wanted to do was expose your own. So the easy way out is to ask people to make instances and the hard way is to somehow identify which module called the decorator. I think the instance thing is the only sane solution.

License

whatever, I don't mind. Google Code made me choose so I went with the "New BSD". If somebody has a better idea, e-mail, comment or whatnot. Hearing from whoever uses this code would be nice, but you really shouldn't feel obliged.

Don't Be Shy

Please comment, mail, or ticket freely. The syntax for this project is far from finalized. Contact me here: ubershmekel at gmail