classification
Title: issue a warning when populating a CPython type dict with non-string keys
Type: behavior Stage:
Components: Interpreter Core Versions: Python 3.3
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: twouters Nosy List: BreamoreBoy, alex, brian.curtin, daniel.urban, haypo, loewis, michael.foord, ncoghlan, pitrou, stutzbach, twouters
Priority: normal Keywords: patch

Created on 2011-03-09 20:53 by michael.foord, last changed 2014-07-11 14:52 by BreamoreBoy.

Files
File name Uploaded Description Edit
issue11455.patch daniel.urban, 2011-03-10 18:50 review
Messages (14)
msg130462 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2011-03-09 20:53
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.
msg130464 - (view) Author: Alex Gaynor (alex) * (Python committer) Date: 2011-03-09 20:54
2 ways to do it:

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

or

type("A", (object,), {42: "abc"})
msg130465 - (view) Author: Michael Foord (michael.foord) * (Python committer) Date: 2011-03-09 20:55
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.
msg130484 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2011-03-10 03:02
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).
msg130510 - (view) Author: Daniel Stutzbach (stutzbach) (Python committer) Date: 2011-03-10 15:54
For what it's worth, I believe this could be implemented easily by calling _PyDict_HasOnlyStringKeys at the end of the class creation process.
msg130512 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2011-03-10 16:28
Can somebody propose a patch?
msg130520 - (view) Author: Daniel Urban (daniel.urban) * Date: 2011-03-10 18:50
> Can somebody propose a patch?

Yes, here it is. (I'm not sure if the test is in the correct file.)
msg130521 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-03-10 18:52
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?)
msg130522 - (view) Author: Alex Gaynor (alex) * (Python committer) Date: 2011-03-10 18:53
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'
msg130523 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2011-03-10 18:55
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.
msg131974 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2011-03-24 13:34
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.
msg131975 - (view) Author: STINNER Victor (haypo) * (Python committer) Date: 2011-03-24 13:43
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.
msg132032 - (view) Author: Daniel Urban (daniel.urban) * Date: 2011-03-24 21:24
> I would prefer an explicit PyExc_RuntimeWarning to not have to read the
> source of PyErr_WarnFormat() or its documentation.

The patch at issue11470 adds a new warning type, CompatibilityWarning. I think probably that should be used here too.
msg222753 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2014-07-11 14:52
The patch is short and sweet.  Assuming it is acceptable do we commit or don't we?  See also the reference to #11470 in msg132032.
History
Date User Action Args
2014-07-11 14:52:26BreamoreBoysetnosy: + BreamoreBoy
messages: + msg222753
2011-05-20 19:52:42brian.curtinsetnosy: + brian.curtin
2011-03-24 21:24:32daniel.urbansetmessages: + msg132032
2011-03-24 13:43:48hayposetmessages: + msg131975
2011-03-24 13:41:45hayposetnosy: + haypo
2011-03-24 13:34:42ncoghlansetassignee: twouters

messages: + msg131974
nosy: + twouters, ncoghlan
2011-03-10 18:55:00pitrousetnosy: loewis, pitrou, stutzbach, alex, michael.foord, daniel.urban
messages: + msg130523
2011-03-10 18:53:45alexsetnosy: loewis, pitrou, stutzbach, alex, michael.foord, daniel.urban
messages: + msg130522
2011-03-10 18:52:20pitrousetnosy: + pitrou
messages: + msg130521
2011-03-10 18:50:17daniel.urbansetfiles: + issue11455.patch

nosy: + daniel.urban
messages: + msg130520

keywords: + patch
2011-03-10 16:28:29loewissetmessages: + msg130512
2011-03-10 15:54:28stutzbachsetnosy: + stutzbach
messages: + msg130510
2011-03-10 03:02:53loewissetnosy: + loewis
messages: + msg130484
2011-03-09 20:55:16michael.foordsetmessages: + msg130465
2011-03-09 20:54:47alexsetnosy: + alex
messages: + msg130464
2011-03-09 20:53:47michael.foordcreate