On 08/07/11 17:59, Armin Rigo wrote:
> I fear that we are going to end up seeing more and more cases where
> users rely on the current CPython behavior, particularly because we're
> going to expose such issues more and more over time as we add new
> optimizations. But I may be wrong and it may be enough to document it
> in cpython-differences.rst.
yes, the whole point of my position is that I don't think there is many code
around relying on this behavior. Thus, I propose to wait a bit and see how
many people complain, before fixing what it might be a non-issue
>> x = 1003
>> d = {x: None}
>> assert d.keys()[0] is x
>> d[1000+3] = None
>> assert d.keys()[0] is x # BOOM
>
> This is the wrong example: in this case, CPython guarantees that it
> will not crash. The semantics are not really half-broken, just not
> written out clearly: when you add an object to a dict, if there is
> another key already in there that compares equal, then the existing
> key is kept; it is not replaced by the new key. (Both CPython and
> PyPy agree to this rule.)
ouch, I should write test for my emails :-)
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
