On Fri, Apr 15, 2016 at 7:31 PM, Victor Stinner <victor.stin...@gmail.com> wrote: > .2016-04-15 23:45 GMT+02:00 Jim J. Jewett <jimjjew...@gmail.com>: ... >> 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
