[issue12719] Direct access to tp_dict can lead to stale attributes

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 6ef65516fd7a by Benjamin Peterson in branch '3.2':
note mutating tp_dict is bad (closes #12719)
http://hg.python.org/cpython/rev/6ef65516fd7a

New changeset 69df5a8d164e by Benjamin Peterson in branch 'default':
merge 3.2 (#12719)
http://hg.python.org/cpython/rev/69df5a8d164e

--
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12719] Direct access to tp_dict can lead to stale attributes

[Benjamin Peterson]

Benjamin Peterson  added the comment:

This is forbidden, and I agree there should be a doc note. See #1878.

--
assignee:  -> docs@python
components: +Documentation -Extension Modules
nosy: +benjamin.peterson, docs@python

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12719] Direct access to tp_dict can lead to stale attributes

[Martin von Gagern]

New submission from Martin von Gagern :

The attached C extension provides a way to manually set an element in the dict 
of an extension type. As the test case exposes, this can result in a 
discrepancy between cls.__dict__['key'] and cls.key.

Please tell me up front if my extension simply does something explixitely 
forbidden, and point me at the documentation saying so.
http://docs.python.org/py3k/c-api/typeobj.html#PyTypeObject.tp_dict at least 
doesn't appear to explicitely forbid my approach, even if it probably is not 
the preferred way.

If you consider what I'm doing to be really evil, you might want to ban that 
practice more clearly, by adding a suitable note to the documentation of the 
tp_dict member.

In case you cannot reproduce, running the attached testcase script with "test" 
as its sole command line argument, I get the following lines, among others:

Traceback (most recent call last):
  File ".../setDictTest.py", line 10, in test1
self.assertEqual(setDictCls.__dict__['key'], setDictCls.key)
AssertionError: 'bar' != 'foo'

I assume that the attribute-style setDictCls.key access will somehow cache its 
result, thus missing the modification to the underlying dict. Just a guess, 
though.

I've had this issue involved in segmentation faults, where the stale object had 
already been finalized. But as the code involved there might have been broken 
in other ways as well, I'll not classify this as type "crash" but only as 
"behaviour".

--
components: Extension Modules
files: setup.py
messages: 141840
nosy: gagern
priority: normal
severity: normal
status: open
title: Direct access to tp_dict can lead to stale attributes
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file22868/setup.py

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com