Bugs item #1448042, was opened at 2006-03-11 23:49
Message generated for change (Comment added) made by zseil
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448042&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Michal Kwiatkowski (rubyjoker)
Assigned to: Nobody/Anonymous (nobody)
Summary: Defining a class with __dict__ brakes attributes assignment
Initial Comment:
When defining a class with __dict__ attribute, its
instances can't rebind their __dict__ attributes.
--------------------------------------------------
class C(object): __dict__ = {}
obj = C()
obj.a = object()
import gc
gc.get_referrers(obj.a) # => [{'a': <object object at
0x811d5b0>}]
obj.__dict__ = {} # doesn't really bind new __dict__
vars(obj) # => {}
object.__getattribute__(obj, '__dict__') # => {}
object.__getattribute__(C, '__dict__') # => {..., but
without "a"}
obj.a # => <object object at 0x811d5b0> (no exception
!)
gc.get_referrers(obj.a) # => [{'a': <object object at
0x811d5b0>, '__dict__': {}}]
--------------------------------------------------
Although neither class nor object has an attribute "a",
it's still accessible. It's also not possible to rebind
__dict__ in that object, as it gets inside real object
attributes dictionary.
This behaviour has been tested on Python 2.2, 2.3 and
2.4, but may as well affect earlier versions.
----------------------------------------------------------------------
Comment By: iga Seilnacht (zseil)
Date: 2006-03-19 14:50
Message:
Logged In: YES
user_id=1326842
Maybe this shows that it is actually a feature?
>>> class C(object):
... pass
...
'__dict__' is not a normal attribute, it's a descriptor
(a "getset_descriptor") generated by object's type.
You can get to this object if you try hard enough:
>>> C_dict_descriptor = C.__dict__['__dict__']
>>> type(C_dict_descriptor).__name__
'getset_descriptor'
This descriptor is automatically created for most of the
python classes (except for those, that have __slots__
without __dict__) by 'type' object.
Since 'type' is an instance of itself, it also has it:
>>> type_dict_descriptor = type.__dict__['__dict__']
And we can see, that it is responsible for creating
the C's __dict__ attribute:
>>> C.__dict__ == type_dict_descriptor.__get__(C, type)
True
As is normal for most of the special named attributes,
this one is looked up in object's type, not in its dict,
and it isn't a normal dict, but a dictproxy:
>>> type(C.__dict__).__name__
'dictproxy'
Now in your case, you create a class attribute '__dict__':
>>> class D(C):
... __dict__ = {'a': 1}
...
Which basically does something like:
>>> name = 'E'
>>> bases = (C,)
>>> E_namespace = {
... '__dict__': {'a': 1},
... '__doc__': "set to None by type if not provided",
... '__module__': "globals()['__name__'] if missing",
... '__weakref__': "another descriptor",
... }
>>> E = type(name, bases, E_namespace)
The '__dict__' attribute of this class is still provided by
its type (type 'type'), and is basicaly just a dictproxy of
the E_namespace:
>>> type(E.__dict__).__name__
'dictproxy'
>>> E.__dict__ == E_namespace
True
What your class definition actually did, is it has
overwritten the __dict__ descriptor that would be
normaly created by type; compare:
>>> C.__dict__['__dict__']
<attribute '__dict__' of 'C' objects>
>>> E.__dict__['__dict__']
{'a': 1}
Now watch what happens if you create an instance of E class:
>>> e = E()
>>> e.__dict__
{'a': 1}
>>> e.a = 2
>>> e.__dict__
{'a': 1}
Basically, now the '__dict__' attribute is a normal
attribute, that behaves just as any other attribute,
while you have lost acces to the instance's inner dict:
>>> e.__dict__ = {}
>>> e.__dict__
{}
>>> e.a
2
If you inherit directly from object, which doesn't have
this descriptor:
>>> object.__dict__['__dict__']
Traceback (most recent call last):
File "<stdin>", line 1, in ?
KeyError: '__dict__'
there would be no way of accesing instance's dictinary.
But since we inherited from class C, we can stil acces it:
>>> C_dict_descriptor.__get__(e)
{'a': 2, '__dict__': {}}
----------------------------------------------------------------------
Comment By: Georg Brandl (gbrandl)
Date: 2006-03-18 18:57
Message:
Logged In: YES
user_id=849994
Reopening. This is a bug, confirmed by Alex Martelli.
----------------------------------------------------------------------
Comment By: Michal Kwiatkowski (rubyjoker)
Date: 2006-03-18 14:01
Message:
Logged In: YES
user_id=1310227
To see an example of rebinding __dict__ usage, go to:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/
66531
It's Alex Martelli implementation of Borg design pattern.
If rebinding __dict__ is forbidden, it should be clearly
noted in the documetation. Either way, it's a bug.
----------------------------------------------------------------------
Comment By: Georg Brandl (gbrandl)
Date: 2006-03-18 09:29
Message:
Logged In: YES
user_id=849994
Agreed with Terry.
----------------------------------------------------------------------
Comment By: Terry J. Reedy (tjreedy)
Date: 2006-03-18 04:21
Message:
Logged In: YES
user_id=593130
To me, this falls under the category of 'don't do that'.
http://docs.python.org/ref/id-classes.html
2.3.2 Reserved classes of identifiers
__*__
System-defined names. These names are defined by the
interpreter and its implementation ...
To me, this means to use them in the manner specified or
you get what you get.
http://docs.python.org/ref/types.html#l2h-120
defines the internal usage of '__dict__'. There is, as
far as I know, no specified usage for rebinding '__dict__'.
So unless someone has a better idea that won't slow down
proper usage, I would close this as 'invalid' or 'wont
fix'.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1448042&group_id=5470
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
