[Python-ideas] Options parsing in the Tornado Web Server
collinw at gmail.com
Thu Sep 10 23:58:35 CEST 2009
On Thu, Sep 10, 2009 at 6:42 PM, Guido van Rossum <guido at python.org> wrote:
> Hey Bret!
> I still see your name in our code base a lot... :-)
> The Google flags code has a fundamentally different use case than the
> typical argument parsing -- thanks for pointing this out. In fact, the
> two use cases are so different that there is barely any overlap. (What
> Google does with flags is more typically done with environment
> variables, although I totally understand that that didn't work for
Other useful notes about the Google flag systems (most of which sounds
like it applies to Tornado's system as well), for those who haven't
- Google's flag system is used primarily for configuring binaries,
rather than command-line option parsing; it just happens to take the
form of command-line options.
- Accordingly, having a single global options dict is useful for
configuring all the different libraries that get linked into a single
binary. Most of the flags a given binary exposes come from these
libraries, or libraries used by other libraries, etc.
- When defining flags in libraries, you have to manually namespace
them (mylibrary_rpc_deadline_secs, yourlibrary_rpc_deadline_secs, etc)
to avoid collisions.
- The flags system is designed to operate across languages: a Python
application can define some flags, and that application may use a C++
extension module which defines more flags, and both are configured in
the same place.
Based on that, I'm not sure that a gflags-like system would be a good
replacement for command-line parsing. In fact, gflags sometimes
requires unexpected/unusual command-line ordering if you try to use it
like a general option parser.
Other people who've used gflags may have a different perspective.
More information about the Python-ideas