Phillip J. Eby wrote:
> At 12:25 PM 11/11/03 -0500, Jim Fulton wrote:
>
>> Tim Peters wrote:
>>
...
>> Surely, the original intent is top break something. ;)
>> I'd much rather get an attribute error than a segfault or an
>> equally fatal C assertion error.
>
>
> What's baffling me is what code is accessing the class after tp_clear is
> called. It can't be a __del__ method, or the cycle collector wouldn't
> be calling tp_clear, right? Or does it run __del__ methods during
> shutdown?
No, it's not a del. An object is being accessed in a weakref callback.
The object being accessed is *not* the obect being accessed by the weakref.
It's an object that had a dictionary that contained the wekref:
class SurrogateRegistry(object):
"""Surrogate registry
"""
def __init__(self):
self._surrogates = {}
def _remove(k, selfref=weakref.ref(self)):
self = selfref()
if self is not None:
try:
del self._surrogates[k]
except KeyError:
pass
self._remove = _remove
This thing is similar to a WeakKeyDictionary. The _remove function is used as a
callback when creating weakrefs of things stored as keys in the _surrogates
dictionary.
Now, it turns out that this function is called at a point where tp_clear has been
called on the class. The problem occurs when the callback tries to do self._surrogates.
(BTW, my workaround is:
class SurrogateRegistry(object):
"""Surrogate registry
"""
def __init__(self):
self._surrogates = surrogates = {}
def _remove(k):
try:
del surrogates[k]
except KeyError:
pass
self._remove = _remove
which avoids accessing "self", but creates a strong reference, and
this a cycle, from the weakref objects to the _surrogates dict,
which is acceptable for my needs.)
Jim
--
Jim Fulton mailto:jim at zope.com Python Powered!
CTO (540) 361-1714 http://www.python.org
Zope Corporation http://www.zope.com http://www.zope.org
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4