Pablo Galindo Salgado <pablog...@gmail.com> added the comment:
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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue44523> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com