[Python-ideas] Options parsing in the Tornado Web Server
btaylor at gmail.com
Thu Sep 10 23:29:38 CEST 2009
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.
On Sep 10, 1:44 pm, Guido van Rossum <gu... at 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... at gmail.com> wrote:
> > I remember seeing a bit of discussion about improving Python's default
> > options parsing... Tornado's seems very impressive :
> >> 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.
> --Guido van Rossum (home page:http://www.python.org/~guido/)
> Python-ideas mailing list
> Python-id... at python.orghttp://mail.python.org/mailman/listinfo/python-ideas
More information about the Python-ideas