Issue 14092: name inconsistently applied in class definition (original) (raw)
Created on 2012-02-22 23:29 by eukreign, last changed 2022-04-11 14:57 by admin. This issue is now closed.
Messages (8)
Author: Lex Berezhny (eukreign)
Date: 2012-02-22 23:29
The following behavior doesn't make sense, especially since it works correctly for other special attributes:
class F: name = "Foo"
F.name 'F' F().name 'Foo' F.name = 'Foo' F.name 'Foo'
Works fine for module and others:
class F: module = "mod"
F.module 'mod' F <class mod.F at 0x0212B360>
Author: Benjamin Peterson (benjamin.peterson) * 
Date: 2012-02-23 01:09
I don't think this is actually incorrect. Basically setting something in the class body is not equivalent to setting it as an attribute on the class.
This happens with other attributes. Consider
class X: ... class = list ... X.class <class 'type'> X().class <class 'list'>
Author: Lex Berezhny (eukreign)
Date: 2012-02-23 01:38
I think for class it might make sense but for name it seems not intuitive.
Author: Benjamin Peterson (benjamin.peterson) *
Date: 2012-02-23 01:43
Well, what do you expect the name of the class to be? The one you assign name to or the one you pass to type()?
Author: Lex Berezhny (eukreign)
Date: 2012-02-23 02:01
The one in name since logically that happens after the class declaration ('class X' line) and should overwrite the name in the class declaration.
Author: Benjamin Peterson (benjamin.peterson) *
Date: 2012-02-23 02:06
It can be implemented but I'm skeptical that it's correct. You might try convincing Python-dev.
Author: Lex Berezhny (eukreign)
Date: 2012-02-23 02:54
I don't particularly need this functionality. It was just something that seemed counter intuitive to me.
I discovered this while working on a python to javascript compiler. I'll probably implement the compiler to allow overriding with name as it seems more intuitive to me that way.
Hopefully cpython will be changed to work that way too.
Author: Terry J. Reedy (terry.reedy) *
Date: 2012-02-25 01:15
This is not a bug report, as Python works as documented. Double underscore names are defined as reserved for the interpreter, with the ones actually in use having defined meanings.
type.new sets several internally used attributes on new classes. The attribute look-up mechanism for classes looks at them first before looking in dict, which is for attributes of both the class and its instances. Here is another example similar to yours.
class C: dict = 1
C.dict dict_proxy({'dict': 1, 'module': 'main', 'weakref': <attribute '__weakref__' of 'C' objects>, 'doc': None}) C().dict 1
dict is not writable, but class is. You can already rename a class if you really want:
C.name = 'bizarre' C.name 'bizarre'
Conceptually, this seems the right way as one normally would not want the name of the class to be the default name for every instance.
C().name Traceback (most recent call last): File "<pyshell#12>", line 1, in C().name AttributeError: 'bizarre' object has no attribute 'name'
If you really want instances to have that also, then also do as you did.
There are other class-only, not for instances, attributes: mro and subclasses and perhaps others.
History
Date
User
Action
Args
2022-04-11 14:57:27
admin
set
github: 58300
2012-02-25 01:15:32
terry.reedy
set
status: open -> closed
type: behavior -> enhancement
versions: - Python 2.6, Python 3.1, Python 2.7, Python 3.2
nosy: + terry.reedy
messages: +
resolution: rejected
2012-02-23 02:54:29
eukreign
set
messages: +
2012-02-23 02:06:18
benjamin.peterson
set
messages: +
2012-02-23 02:01:32
eukreign
set
messages: +
2012-02-23 01:43:23
benjamin.peterson
set
messages: +
2012-02-23 01:38:20
eukreign
set
messages: +
2012-02-23 01:09:43
benjamin.peterson
set
nosy: + benjamin.peterson
messages: +
2012-02-22 23:37:11
eukreign
set
versions: + Python 3.3
2012-02-22 23:29:07
eukreign
create