[issue9658] weakref.proxy unequal to its referent in 2.x

Mark Dickinson report at bugs.python.org
Sat Aug 21 21:44:22 CEST 2010


New submission from Mark Dickinson <dickinsm at gmail.com>:

Nicholas Cole noted on python-list that the behaviour of weakref.proxy with respect to equality changed between 2.x and 3.x:

Python 2.7 (r27:82500, Aug 15 2010, 14:21:15) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin 
Type "help", "copyright", "credits" or "license" for more information. 
>>> import weakref 
>>> s = set() 
>>> s == weakref.proxy(s) 
False 

Python 3.1.2 (r312:79147, Aug 20 2010, 20:06:00) 
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin 
Type "help", "copyright", "credits" or "license" for more information. 
>>> import weakref 
>>> s = set() 
>>> s == weakref.proxy(s) 
True

This seems to be an inadvertent change resulting from the switch from 3-way comparisons to rich comparisons:  the 2.x source implements tp_compare for proxy objects.  The tp_compare slot *does* unwrap the proxy objects before comparing, but since the tp_compare slot in general  is only ever called (for objects implemented in C) when the types of the objects being compared are the same, a proxy object won't compare equal to its referent.

I believe that Nicholas ran into this when using weakrefs as elements of containers.  Nicholas:  is that right?  Care to elaborate?

The 3.x source changes this to use tp_richcompare (see r51533), so now a proxy object *does* compare equal to its referent.

The 3.x behaviour seems better to my limited eyes, and the 2.x behaviour has been around a long time without causing problems, so we probably don't want to change the behaviour in either case.  But it might be good to document the difference somewhere.

----------
messages: 114557
nosy: mark.dickinson
priority: normal
severity: normal
status: open
title: weakref.proxy unequal to its referent in 2.x
type: behavior
versions: Python 2.6, Python 2.7

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue9658>
_______________________________________


More information about the Python-bugs-list mailing list