Code
====

- The __name__-aversion in the mapping interface is a little
  heavy-handed, but given the implementation of __name__ elsewhere, I
  think this can be revisited separately if anyone cares enough.

  In particular, it should be allowed to give an __name__ value
  explicitly and have it exposed:

      >>> import configparser
      >>> import io

      >>> cp = configparser.RawConfigParser()
      >>> cp.read_file(io.StringIO('[sect]\n__name__ = FooBar\n'))

      >>> cp.get('sect', '__name__')
      'FooBar'

      >>> cp['sect']['__name__']
      Traceback (most recent call last):
        File "<stdin>", line 1, in <module>
        File ".../py3k/Lib/configparser.py", line 1132, in __getitem__
          raise ValueError(self._noname)
      ValueError: __name__ special key access and modification not supported through the mapping interface.

  In this example, the __name__ key isn't special, it's just a key.

Documentation
=============

- I dislike the 'fallback'/'default' terminology problem; everywhere
  else, the fallback is called 'default'.  This really points to
  configparser (ne ConfigParser) not having been fully thought out
  before it was released as part of Python.  There's probably nothing
  to be done about it at this point.

  Has anyone attempted to determine how widely used the "defaults"
  (mis-)feature is?  I've not seen a good user for it as implemented
  outside the original application ConfigParser was written for
  (though others probably exist that have a similar need).

- There's no value in saying

      `None` can be provided as a `fallback` value.

  (regardless of the terminology).  None is a value like any other, and
  the docs already indicate it is used if provided.  If anything need be
  said, identify the exception raised if the default isn't provided and
  no value is present.

  Identifying None as a possible value isn't needed or done in any of
  the mapping descriptions, so let's not add it here, even for the
  methods that don't correlate to mapping methods.

- I dislike the documentation style where we indicate arguments are
  keyword-only using a bare * in the signature, and then repeat that in
  prose (this is not the only place this happens).  It's redundant
  (more work to maintain) and more verbose than helpful.

I still need to give the new docs a thorough read.