Fred L. Drake, Jr. <fdr...@acm.org> added the comment:
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.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue5412>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
