Jarek Potiuk added the comment:
How about if we make PR instead to the documentation about this behaviour?
I think this behaviour is a little surprising (you need to know the internals
of how WeakKeyDict keys are constructed and checked) and while I understand you
do not want breaking
Raymond Hettinger added the comment:
I concur with Jelle and Methane that we can't do this without breaking code.
Also if you don't care about dict order, the work around is easy. Just remove
the old key:
d.pop(k); d[k] = v
--
nosy: +rhettinger
resolution: -> rejected
stage:
Jelle Zijlstra added the comment:
As @methane also said on the PR, this is a backward compatibility break and we
can't just change the behavior. I'd be opposed to a change here: the proposed
behavior isn't clearly better than the existing behavior (sometimes you want
one behavior, sometimes
New submission from Malthe Borch :
When a key that is equal to an existing key (but not the same object identity)
is used to set a new value, the key itself is not replaced.
This manifests perhaps most clearly in `weakref.WeakKeyDictionary` where keys
can mysteriously disappear.
Consider
