-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WeakKeyDict should not convert keys as otherwise it can drop them #24941
Comments
This should get the |
WeakKeyDict should really be WeakKeyIdDict, anything else is pretty broken. |
I realize it's very late in the game, but is it fundamentally broken for |
No, I don't think it's fundamentally broken. The weakness controls when keys get deleted, and the comparison controls which keys can be found. For example if |
I totally agree that the ID-version makes more sense. With the non-ID version, I cannot imagine a situation when conversion of the key upon insertion is the desired outcome. Do you have an example when that could be useful and not a bug? (I'm ok with comparison doing a "conversion") |
Ok, the current version isn't "fundamentally broken" in the sense that it crashes or gives incorrect behavior, but I cannot imagine a situation where someone is using a |
A recent data point in favor of that here. |
I implemented the using-object-id change in PR #28161, maybe this can help the triage-call tomorrow. |
See #3002 --- |
I found three occurences of WeakKeyDict in stdlib (and none in
As per Jeff's comment, the first two need It would probably be good though to add tests which test the |
Thanks for the investigation, @mauro3! The conclusion from discussion on the triage call is that we should just make the minimal change here and make |
Cool, I can prepare a PR tomorrow. Did you discuss whether the no-conversion applies to getters as well? |
We said getters should continue to convert – it's just setters that should type-assert. |
but I guess that is ok. Or maybe more consistent to throw on the first too? (The latter would be easier to implement ;-) |
I would favor erroring on the first one too. |
For those following along at home and still wondering when the |
Consider:
I would argue that this is not the intended behavior and instead an error should be thrown on
wkh[v] = 1
. Although, maybe there is a use for this which escapes me, e.g. hash consing, see #3002.Open questions:
k1==k2
does not implywkh[k1]==wkh[k2]
. Not sure whether this is bad or not (or worse than above example).I'm not sure whether this issue should be classified as breaking (I guess that depends whether the behavior is a bug or a feature).
I have a branch in which I changed this here, which I could turn into a PR. Alternatively, if this is a feature and not a bug, a test should be added. Could above example be used or is that too fragile due to
gc()
?The text was updated successfully, but these errors were encountered: