I am Bret from FriendFeed, author of a lot of Tornado. We modeled it after the Google option parsing (http://code.google.com/ p/google-gflags/). The main distinction is that every module declares its own options, so your main() function doesn't need to be aware of all of the options used by the transitive closure of modules in your server. As anyone who has worked on large systems knows, passing around options and defaults becomes a big pain after your number of modules increases above 100 or so. That said, I think our options parsing works well for individual projects, but you would get lots of naming conflicts if it were adopted in any official capacity by Python given the options all have global scope, so I agree with Guido that optparse is probably better as an official module. It certainly was much more useful to us than optparse from an operational standpoint, though. Bret On Sep 10, 1:44 pm, Guido van Rossum <gu...@python.org> wrote:
That's not particularly more expressive than what optparse gives you today, except for the use of a function with a side effect on a magic global (how the heck did options.port suddenly get a value?!) and the potential for confusing tornado.options with tornado.options.options.
On Thu, Sep 10, 2009 at 12:50 PM, Andrey Fedorov <anfedo...@gmail.com> wrote:
I remember seeing a bit of discussion about improving Python's default options parsing... Tornado's seems very impressive [1]:
from tornado.options import define, options
define("port", default=8888, help="run on the given port", type=int)
print options.port
What does everyone think?
- Andrey
1. http://github.com/facebook/tornado/blob/9a8bd2fb6fd6279be16d6f0a2e57e...
-- --Guido van Rossum (home page:http://www.python.org/~guido/) _______________________________________________ Python-ideas mailing list Python-id...@python.orghttp://mail.python.org/mailman/listinfo/python-ideas