twisted.python.usage can't tell the difference between set opts and defaulted-to opts

New submission from lvh <[email protected]>:

= What? =

twisted.python.usage.Options subclasses dict and has `self.opts = self` in `__init__`. As a result of this, there currently is no sane way to differentiate between an option that was actually set and an option that was defaulted to.

= Why? =

Knowing the difference can be useful. My use case, for example, is a situation where I have three layers of precedence in terms of configuration for my app:

   1. command line options (highest)
   2. configuration file options
   3. default values (lowest)

Since there are tools for which all of these parse to dicts (twisted.python.usage and pyyaml, for example), the precedence can be elegantly done using dict.update. Unfortunately, this requires knowing if a value in my options object was actually *set*, or merely defaulted to.

= How? =

See attached proposed patch.

== Alternatives ==

=== `__eq__` (comparison) ===
The user of Option could do this: `option[opt] if option.defaults[opt] != option[opt] else None`, but that would cause possibly wrong behavior when a user manually sets something to a value Option would consider default. Example: port number, global value is 9999, config file value is 8888, user sets 9999 on the command line, expected: 9999 (but wouldn't work because it's equal to the default). This is more of a workaround, IMHO.

=== Adding a third dict ===
This would be a workaround that (at least, I think) wouldn't break existing any code. It would introduce a new dict, self.setopts, which would behave the same as self.opts behaves in the proposed patch, and keep the behavior of self.opts = self.

If you like this more, I'm willing to write the patch that does this last thing, too.

----------
Type     : enhancement
Component: core
Keywords : usage review
Priority : normal
Nosy     : 
----------
http://twistedmatrix.com/trac/ticket/3890