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

[Collin Winter]

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
> you.)

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
used it:
- 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.

Collin Winter