Author: Alex Gaynor <alex.gay...@gmail.com>
Branch: extradoc
Changeset: r5108:5acdadcc32fd
Date: 2013-11-09 08:02 -0800
http://bitbucket.org/pypy/extradoc/changeset/5acdadcc32fd/
Log: This was also done
diff --git a/planning/primitive-identity.rst b/planning/primitive-identity.rst
deleted file mode 100644
--- a/planning/primitive-identity.rst
+++ /dev/null
@@ -1,70 +0,0 @@
-Primitive objects and object identity
-=====================================
-
-Hi all,
-
-Recently PyPy merged a pretty big branch that allows for transparently
-type-specializing dictionaries. That means if you write something like::
-
- strs = {x: str(x) for x in xrange(100000)}
-
-The dictionary would be specialized for integer keys, obviating the need to
-allocate W_IntObjects (PyPy's equivalent to PyIntObject).
-
-This, however introduces interesting behavior surrounding object identity
-(*only* with respect to primitive objects, none of what is discussed affects
-either mutable, or user-defined objects), specifically the follow code no
-longer works::
-
- x = int(x)
- z = {x: None}
- assert next(iter(z)) is x
-
-This would similiarly fail if you replaced is with comparing the id()s. The
-question now is, is this behavior a violation of the Python language
-definition, or is it a legal, interpreter defined difference?
-
-There are several arguments in favor:
-
-1) It is easier to implement this way, and removes complexity in the
- interpreter implementation, and allows for better performance.
-
-2) For all of these objects, identity is trivial. That is to say identity could
- always be replacement by an equality test and no semantics would be
violated.
- In that respect requiring that identity be maintained adds no value, the
- new object is completely indistinguishable
-
-3) A reliance on object identity leads to some rather strange behavior, a good
- example of this is a recent discussion about the identity shortcut in
- ``dict.__contains__`` and ``list.__contains__``, specifically in the case of
- ``nan``. At present if you have a ``dict`` with a ``nan`` key the only way
- to retreive that value is to use the exact same ``nan`` object, another one
- will not do because ``nan`` does not have reflexive identity. Even on
- CPython, passing around this object could easily lose it's identity, for
- example various functions in the ``math`` module return a ``nan`` given a
- ``nan`` argument, but they make no guarntee that they return the same
- instance, furthering a reliance on any such behavior is wrong, given that
- equality is always a valid substitute.
-
-And arguments against::
-
-1) It may break some existing code (so far the only such code I've found is in
- the Python test suite, it was not testing this behavior directly, but rather
- incidentally relied on it).
-
-
-I can find no other argument against it.
-
-Note that should we decide that this is in fact a violation of the language
-spec, the resulting behavior in PyPy will be for identity to be equality on
-primitive type objects. That is to say, the following code would work::
-
- assert all([
- x is (x + 1 - 1)
- for x in xrange(sys.minint, sys.maxint)
- ])
-
-As actually assigning allocating W_IntObjects will not occur.
-
-Opinions welcome,
-Alex
_______________________________________________
pypy-commit mailing list
pypy-commit@python.org
https://mail.python.org/mailman/listinfo/pypy-commit
