[New-bugs-announce] [issue10489] configparser: remove broken `__name__` support

Łukasz Langa report at bugs.python.org
Sun Nov 21 13:30:54 CET 2010

New submission from Łukasz Langa <lukasz at langa.pl>:

I want to sum up all strange things about the behaviour of `__name__`, a special key present in every section of a parser instance.

1. There is a special `__name__` key in every section.
2. Except for the DEFAULTSECT.
3. `__name__` key is set for every section read from a file.
4. and not when adding by `add_section()`.
5. if `__name__` does exist, it's not visible in `parser.options('section')`
6. but it is visible here: `parser.has_option('section', '__name__') == True`
7. and can be obtained by `parser.get('section', '__name__')`
8. and can be changed by `parser.set('section', '__name__', 'ANY VALUE')`
9. and can be removed by `parser.remove_option('section', '__name__')`
10. even if the value is changed by `parser.set()`, it won't be written back to a file with `parser.write()`

All this looks like a feature that was not particularly complete and well defined when it was first created. Or possibly, it became rotten with time and now nobody is using it anyway. That way or the other, I couldn't come up with a valid use case for `__name__` with the current implementation. It doesn't serve any internal purpose and the *only* way you can actually get it is to `parser.get('section', '__name__')` which returns 'section' anyway. About as useless as it gets. Of course, one can go and take the internal parser._sections data structure of the parser but that's evil.

I want simply remove all mentions of a special `__name__` key in configparser.py. Backwards compatibility is not a concern here because in this case we have a concept that is so broken that you can't actually use it.

assignee: lukasz.langa
components: Library (Lib)
keywords: easy, needs review
messages: 121912
nosy: lukasz.langa
priority: normal
severity: normal
status: open
title: configparser: remove broken `__name__` support
type: behavior
versions: Python 3.2

Python tracker <report at bugs.python.org>

More information about the New-bugs-announce mailing list