Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

configparser: remove broken __name__ support #54698

Closed
ambv opened this issue Nov 21, 2010 · 4 comments
Closed

configparser: remove broken __name__ support #54698

ambv opened this issue Nov 21, 2010 · 4 comments
Assignees
Labels
easy stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error

Comments

@ambv
Copy link
Contributor

ambv commented Nov 21, 2010

BPO 10489
Nosy @freddrake, @birkenfeld, @merwok, @voidspace, @ambv
Files
  • issue10489.diff: Patch for removal of the broken __name__ key
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = 'https://github.com/ambv'
    closed_at = <Date 2010-11-21.14:00:34.494>
    created_at = <Date 2010-11-21.12:30:53.412>
    labels = ['easy', 'type-bug', 'library']
    title = 'configparser: remove broken `__name__` support'
    updated_at = <Date 2010-11-21.14:00:34.492>
    user = 'https://github.com/ambv'

    bugs.python.org fields:

    activity = <Date 2010-11-21.14:00:34.492>
    actor = 'lukasz.langa'
    assignee = 'lukasz.langa'
    closed = True
    closed_date = <Date 2010-11-21.14:00:34.494>
    closer = 'lukasz.langa'
    components = ['Library (Lib)']
    creation = <Date 2010-11-21.12:30:53.412>
    creator = 'lukasz.langa'
    dependencies = []
    files = ['19742']
    hgrepos = []
    issue_num = 10489
    keywords = ['patch', 'easy', 'needs review']
    message_count = 4.0
    messages = ['121912', '121913', '121920', '121928']
    nosy_count = 5.0
    nosy_names = ['fdrake', 'georg.brandl', 'eric.araujo', 'michael.foord', 'lukasz.langa']
    pr_nums = []
    priority = 'normal'
    resolution = 'accepted'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue10489'
    versions = ['Python 3.2']

    @ambv
    Copy link
    Contributor Author

    ambv commented Nov 21, 2010

    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.

    @ambv ambv self-assigned this Nov 21, 2010
    @ambv ambv added stdlib Python modules in the Lib dir easy type-bug An unexpected behavior, bug, or error labels Nov 21, 2010
    @ambv
    Copy link
    Contributor Author

    ambv commented Nov 21, 2010

    For the record, I wrote about this problem in July on the mailing list [1], there were no replies.

    [1] http://mail.python.org/pipermail/python-dev/2010-July/102556.html

    @ambv
    Copy link
    Contributor Author

    ambv commented Nov 21, 2010

    Patch for the cleanup attached. 47 lines removed, about a half of these were in tests explicitly made to check for these inconsistencies. 4 lines added, all of them are reformattings due to removal of the other lines.

    Syntax highlighted view of the patch:
    http://bpaste.net/show/11395/

    @ambv
    Copy link
    Contributor Author

    ambv commented Nov 21, 2010

    Committed in rev 86638. A public API for getting the name of the section from a SectionProxy instance was introduced in 86639. This is useful because you can assing a section proxy to a variable and pass it around:

    >>> from configparser import SafeConfigParser
    >>> parser = SafeConfigParser()
    >>> parser.read_string("""
    ... [section1]
    ... value = A
    ... value2 = B
    ... 
    ... [section2]
    ... value = C
    ... value2 = D
    ... """)
    >>> section1 = parser['section1']
    >>> section1['value']
    'A'
    >>> section1.name
    'section1'
    >>> section2 = parser['section2']
    >>> section2['value']
    'C'
    >>> section2.name
    'section2'
    >>> section2.name = 'cannot do that, this attribute is read-only on a SectionProxy'
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    AttributeError: can't set attribute

    @ambv ambv closed this as completed Nov 21, 2010
    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    easy stdlib Python modules in the Lib dir type-bug An unexpected behavior, bug, or error
    Projects
    None yet
    Development

    No branches or pull requests

    1 participant