[Python-ideas] Options parsing in the Tornado Web Server

[Nick Coghlan]

Andrey Fedorov wrote:
> Well, options._port_ corresponds to define("_port_", ...). Is it
> considered unPythonic to equate variable names and strings? I didn't
> think it was, since scopes are dictionaries...

It's the fact that there is an options global in the module at all which
can be surprising.

Application global objects like that aren't necessarily bad, but they
aren't necessarily good either. optparse uses independent parsers by
default, leaving applications free to put the options information
wherever they want (e.g. merging it with settings coming from system and
per-user configuration files and storing the results in a myapp.settings
module)

An approach like the tornado example that provides its own global parser
better also have its own mechanism for producing additional independent
parsers if it ever hopes to match the features of optparse.

Aside from the presence of that global parser, I'm not seeing a lot
difference between options.define and parser.add_option though.

Anyone wanting to replace/compete with optparse (particularly with goals
for latter standard library inclusion) would do well to better
articulate what they don't like about optparse though. I acknowledge
that using optparse the first couple of times can have something of a
learning curve, but that's because it is rather powerful.

And if there are features that appear to be missing, then why not
suggest those as optparse enhancements rather than trying to replace the
module wholesale?

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------