On Thu, Sep 10, 2009 at 6:42 PM, Guido van Rossum <guido@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