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@gmail.com | Brisbane, Australia ---------------------------------------------------------------