[Python-Dev] Fighting the theoretical randomness of "is" on immutables

[Nick Coghlan]

On Mon, May 6, 2013 at 6:46 PM, Armin Rigo <arigo at tunes.org> wrote:
> This is clearly a language design issue though.  I can't really think
> of a use case that would break if we relax the requirement, but I
> might be wrong.  It seems to me that at most some modules like pickle
> which use id()-keyed dictionaries will fail to find some
> otherwise-identical objects, but would still work (even if tuples are
> "relaxed" in this way, you can't have cycles with only tuples).

IIRC, Jython just delays calculating the object id() until it is
called, and lives with it potentially being incredibly expensive to
calculate. Is there some way PyPy can run with a model where "is" is
defined in terms of values for immutable objects, with a lazily
populated mapping from values to numeric ids if you're forced to
define them through an explicit call to id()?

We're not going to change the language design because people don't
understand the difference between "is" and "==" and then wrongly blame
PyPy for breaking their code. If you're tired of explaining to people
that it's their code which is buggy rather than PyPy, then your
Solution 2 (mimic'ing CPython's caching) is likely your best bet.

Alternatively, we've offered to add CompatibilityWarning to CPython in
the past (there may even be a preliminary patch for it on the
tracker). That offer is still open, and would be applicable to this
case.

Regards,
Nick.

--
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia