On Fri, Apr 15, 2016 at 7:31 PM, Victor Stinner
.2016-04-15 23:45 GMT+02:00 Jim J. Jewett
I just worry that you may end up closing off even better optimizations later, if you make too many promises about exactly how you will do which ones.
Today, dict only cares about ==, and you (reasonably) think that full == isn't always worth running ... but when it comes to which tests *are* worth running, I'm not confident that the answers won't change over the years.
I checked, currently there is no unit test for a==b, only for a is b. I will add add a test for a==b but a is not b, and ensure that the version is increased.
Again, why? Why not just say "If an object is replaced by something equal to itself, the version_tag may not be changed. While the initial heuristics are simply to check for identity but not full equality, this may change in future releases."
For example, if I know that my dict values are all 4-digit integers, can I write:
d[k] = d[k] + 0
and be assured that the version_tag will bump? Or is that something that a future optimizer might optimize out?
Hum, I will try to clarify that.
I would prefer that you clarify it to say that while the initial patch doesn't optimize that out, a future optimizer might.
The problem with storing an identifier (a pointer in C) with no strong reference is when the object is destroyed, a new object can likely get the same identifier. So it's likely that "dict[key] is old_value_id" can be true even if dict[key] is now a new object.
Yes, but it shouldn't actually be destroyed until it is removed from the dict, which should change version_tag, so that there will be no need to compare it.
Do you want to modify the PEP 509 to fix this issue? Or you don't understand why the PEP 509 cannot be used to fix the issue? I'm lost...
I believe it *does* fix the issue in some (but not all) cases. -jJ