This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author pablogsal
Recipients aleneum, docs@python, jack__d, pablogsal
Date 2021-06-28.16:17:27
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1624897047.59.0.46676787666.issue44523@roundup.psfhosted.org>
In-reply-to
Content
In my view, proxies should behave almost exactly as the underliying object, so using them is as ergonomic as possible. For instance, when using them as a way to avoid cycles, is quite annoying if you have a hashable object in a dictionary and they fail to tell you that is there:

>>> class A:
...   ...
...
>>> a = A()
>>> d = {a: None}
>>> weakref.proxy(a) in d
True

but doing this in 3.8 is impossible:

>>> import weakref
>>> class A:
...    ...
...
>>> a = A()
>>> d = {a: None}
>>> weakref.proxy(a) in d
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'weakproxy'

Which defies a lot of use cases of this. Notice that if the object is not hashable because the author of the class wants to prevent against that it will work as expected:

>>> class A:
...    __hash__ = None
...
>>> a = A()
>>> hash(weakref.proxy(a))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'A'

This also gives a better error message because it explains that A is not hashable.
History
Date User Action Args
2021-06-28 16:17:27pablogsalsetrecipients: + pablogsal, docs@python, aleneum, jack__d
2021-06-28 16:17:27pablogsalsetmessageid: <1624897047.59.0.46676787666.issue44523@roundup.psfhosted.org>
2021-06-28 16:17:27pablogsallinkissue44523 messages
2021-06-28 16:17:27pablogsalcreate