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

issue a warning when populating a CPython type dict with non-string keys #55664

Closed
voidspace opened this issue Mar 9, 2011 · 17 comments
Closed
Assignees
Labels
3.13 new features, bugs and security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement

Comments

@voidspace
Copy link
Contributor

voidspace commented Mar 9, 2011

BPO 11455
Nosy @loewis, @Yhg1s, @ncoghlan, @pitrou, @vstinner, @alex, @voidspace, @briancurtin, @durban, @serhiy-storchaka, @iritkatriel
Files
  • issue11455.patch
  • 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/Yhg1s'
    closed_at = None
    created_at = <Date 2011-03-09.20:53:47.152>
    labels = ['interpreter-core', 'type-feature', '3.11']
    title = 'issue a warning when populating a CPython type dict with non-string keys'
    updated_at = <Date 2021-12-02.09:24:17.831>
    user = 'https://github.com/voidspace'

    bugs.python.org fields:

    activity = <Date 2021-12-02.09:24:17.831>
    actor = 'serhiy.storchaka'
    assignee = 'twouters'
    closed = False
    closed_date = None
    closer = None
    components = ['Interpreter Core']
    creation = <Date 2011-03-09.20:53:47.152>
    creator = 'michael.foord'
    dependencies = []
    files = ['21072']
    hgrepos = []
    issue_num = 11455
    keywords = ['patch']
    message_count = 16.0
    messages = ['130462', '130464', '130465', '130484', '130510', '130512', '130520', '130521', '130522', '130523', '131974', '131975', '132032', '222753', '407472', '407520']
    nosy_count = 12.0
    nosy_names = ['loewis', 'twouters', 'ncoghlan', 'pitrou', 'vstinner', 'stutzbach', 'alex', 'michael.foord', 'brian.curtin', 'daniel.urban', 'serhiy.storchaka', 'iritkatriel']
    pr_nums = []
    priority = 'normal'
    resolution = None
    stage = None
    status = 'open'
    superseder = None
    type = 'enhancement'
    url = 'https://bugs.python.org/issue11455'
    versions = ['Python 3.11']

    Linked PRs

    @voidspace
    Copy link
    Contributor Author

    It is valid in CPython to create a new type with non-string keys in the dict. This is a problem for other implementations (neither pypy nor jython support it).

    This should raise a warning.

    @voidspace voidspace added type-bug An unexpected behavior, bug, or error interpreter-core (Objects, Python, Grammar, and Parser dirs) labels Mar 9, 2011
    @alex
    Copy link
    Member

    alex commented Mar 9, 2011

    2 ways to do it:

    class A(object):
        locals()[42] = "abc"

    or

    type("A", (object,), {42: "abc"})

    @voidspace
    Copy link
    Contributor Author

    Note that other implementations not supporting this has been agreed by Guido. The language spec says that the class dict is a namespace and should have string keys.

    @loewis
    Copy link
    Mannequin

    loewis mannequin commented Mar 10, 2011

    I fail to see the need to warn about this, though. Users using the feature are likely aware that this violates the language specification, and will find out quickly when they do port it to another Python implementation.

    There are many many other aspects of CPython that don't, and often even can't, work on other Python implementations that are not warned about (such as usage of extensions modules, or development of extension modules).

    @stutzbach
    Copy link
    Mannequin

    stutzbach mannequin commented Mar 10, 2011

    For what it's worth, I believe this could be implemented easily by calling _PyDict_HasOnlyStringKeys at the end of the class creation process.

    @loewis
    Copy link
    Mannequin

    loewis mannequin commented Mar 10, 2011

    Can somebody propose a patch?

    @durban
    Copy link
    Mannequin

    durban mannequin commented Mar 10, 2011

    Can somebody propose a patch?

    Yes, here it is. (I'm not sure if the test is in the correct file.)

    @pitrou
    Copy link
    Member

    pitrou commented Mar 10, 2011

    How about the case where non-string keys are added after the class is created?
    (I think I've heard some third-party lib does this, perhaps a generic functions implementation?)

    @alex
    Copy link
    Member

    alex commented Mar 10, 2011

    How can they be set afterwords?

    alex@alex-laptop:~/projects/pypy$ python3.1 
    Python 3.1.2 (release31-maint, Sep 17 2010, 20:34:23) 
    [GCC 4.4.5] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> class A(object):
    ...     pass
    ... 
    >>> A.__dict__[32] = "heh"
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: 'dict_proxy' object does not support item assignment
    >>> setattr(A, 32, "heh")
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: attribute name must be string, not 'int'

    @pitrou
    Copy link
    Member

    pitrou commented Mar 10, 2011

    Hmm, that's true (although there's a trick using gc.get_referers(), IIRC).
    I was probably thinking about instance dicts rather than type dicts, then.

    @ncoghlan
    Copy link
    Contributor

    Thomas, I know you've been working on this post-Pycon. Could you please take a look at Daniel's patch and/or publish your own.

    @vstinner
    Copy link
    Member

    Cool, someone uses my PyErr_WarnFormat() function! :-) I didn't know that NULL can be used for the category: I would prefer an explicit PyExc_RuntimeWarning to not have to read the source of PyErr_WarnFormat() or its documentation.

    @durban
    Copy link
    Mannequin

    durban mannequin commented Mar 24, 2011

    I would prefer an explicit PyExc_RuntimeWarning to not have to read the
    source of PyErr_WarnFormat() or its documentation.

    The patch at bpo-11470 adds a new warning type, CompatibilityWarning. I think probably that should be used here too.

    @BreamoreBoy
    Copy link
    Mannequin

    BreamoreBoy mannequin commented Jul 11, 2014

    The patch is short and sweet. Assuming it is acceptable do we commit or don't we? See also the reference to bpo-11470 in msg132032.

    @iritkatriel
    Copy link
    Member

    Reproduced on 3.11.

    >>> A = type("A", (object,), {42: "abc"})
    >>> dir(A())
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
    TypeError: '<' not supported between instances of 'int' and 'str'

    @iritkatriel iritkatriel added 3.11 only security fixes type-feature A feature request or enhancement and removed type-bug An unexpected behavior, bug, or error labels Dec 1, 2021
    @serhiy-storchaka
    Copy link
    Member

    Why not raise an error if it contradicts language spec?

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    @iritkatriel iritkatriel added 3.12 bugs and security fixes and removed 3.11 only security fixes labels Oct 7, 2022
    @furkanonder
    Copy link
    Sponsor Contributor

    The PR is ready for review.

    @erlend-aasland erlend-aasland added 3.13 new features, bugs and security fixes and removed 3.12 bugs and security fixes labels Jan 5, 2024
    serhiy-storchaka pushed a commit that referenced this issue Jan 28, 2024
    …ry with non-string keys. (GH-105338)
    
    Co-authored-by: Daniel Urban <durban@users.noreply.github.com>
    aisk pushed a commit to aisk/cpython that referenced this issue Feb 11, 2024
    …ctionary with non-string keys. (pythonGH-105338)
    
    Co-authored-by: Daniel Urban <durban@users.noreply.github.com>
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    3.13 new features, bugs and security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) type-feature A feature request or enhancement
    Projects
    None yet
    Development

    No branches or pull requests

    10 participants