Hi,
2013/5/5 Armin Rigo <ar...@tunes.org>
> Hi all,
>
> I'm just wondering again about some "bug" reports that are not bugs,
> about people misusing "is" to compare two immutable objects. The
> current situation in PyPy is that "is" works like "==" for ints,
> longs, floats or complexes. It does not for strs or unicodes or
> tuples. Now of course someone on python-dev was (indirectly)
> complaining that you can compare in CPython ``x is ' '``, which works
> because single-character strings are cached, but not in PyPy. I'm
> sure someone else has been bitten by writing in CPython ``x is ()``,
> which is also cached there.
>
Strings are not always cached; with CPython2.7:
>>> x = u'é'.encode('ascii', 'ignore')
>>> x == '', x is ''
(True, False)
> (Fwiw I think that there is a design flaw somewhere in Python, to
> allow "1 is 1" to be executed without any error but also without any
> well-defined result...)
>
> Can we fix it once and for all? It's annoying because of id: if we
> want ``x is y`` for equal huge strings x and y, but still want
> ``id(x)==id(y)``, then we have to compute ``id(some_string)`` in a
> rather slow way, producing a huge number. The same for tuples: if we
> always want ``(1, 2) is (1, 2)`` then we need to compute
> ``id(some_tuple)`` recursively, which can also lead to huge numbers.
> In fact such a definition can explode the memory: ``a = (); for i in
> range(100): a = (a, a); id(a)`` would likely need a 2**100-digits
> number.
>
> Solution 2 would be to add these hacks specially for cases that
> CPython caches: I think by now we're only missing empty or single-char
> strings or unicodes, and empty tuple.
>
> Solution 3 would be to drop half of the rule, keeping only
> ``id(x)==id(y) => x is y``. This would be the easiest, as we could
> remove the complicated computations already done for longs or floats
> or complexes. We'd clearly document it as a difference from CPython.
> The question is what kind of code might break if we drop the case ``x
> is y => id(x)==id(y)``.
>
>
> A bientôt,
>
> Armin.
> _______________________________________________
> pypy-dev mailing list
> pypy-dev@python.org
> http://mail.python.org/mailman/listinfo/pypy-dev
>
--
Amaury Forgeot d'Arc
_______________________________________________
pypy-dev mailing list
pypy-dev@python.org
http://mail.python.org/mailman/listinfo/pypy-dev
