a ConfigParser wtf moment

[grahamd at dscpl.com.au]

True, wasn't thinking. This will affect get() as well. My problem was a
slightly different problem.

In your case you would have got what you wanted if get()/items()
instead of being implemented as:

.        try:
.            value = d[option]
.        except KeyError:
.            raise NoOptionError(option, section)

Was implemented as:

.        try:
.            value = self._sections[section][option]
.        except KeyError:
.            raise NoOptionError(option, section)

That is, get the raw value from the original dictionary for the
section. That way you avoid picking up a value from the user
supplied vars. It does also avoid picking a key which has come
through from the default section, but that could easily be
accomodated if that was perceived to be expected behaviour
by having the except clause fall through to looking in the
default section. Similarly if seen that getting it from vars is
okay as well, fall back onto that as file step. All depends on
what the perceived overridding priority is.

At the moment vars overrides section which overrides default
and the document sort of does say that that is what one should
expect for vars at least:

.  Additional substitutions may be provided using the
.  `vars' argument, which must be a dictionary whose contents overrides
.  any pre-existing defaults.

Probably not what I would have expected either. I would have expected
vars to be available for substitution but not for option selection in
the
first place.
It is too late on a Friday, so I may be hallucinating now. :-)