Hi Anto,
On Fri, Jul 8, 2011 at 5:40 PM, Antonio Cuni <anto.c...@gmail.com> wrote:
> My point is that we are not breaking id(); identity dicts emulated using id()
> continue to work as normal.
Well, the argument goes like this: *if* we think that the problems
like the one you describe are to be fixed, then we really need to hack
at "is", and *then* we have a problem with id() as well, and we have
to fix it as I described. You can also try to argue that nothing is
broken so far, neither in "is" nor in id() nor your examples.
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.
> 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.)
A bientôt,
Armin.
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
