Personally, I think that being implementation detail compatible with CPython is the way tio go if we want to achieve maximum popularity in the short run.
Making a sane implementation (Armins third option) is the one that I think will serve the Python community in the best way in the long run. Using "is" as a comparison when you mean "==" is a bad meme that has been very hard to get rid of. The person who's opinion on this matter that I would value the most is Guido's. I suggest asking him. Jacob Sunday 05 May 2013 you wrote: > Hi all, > > On Sun, May 5, 2013 at 9:16 PM, Steven D'Aprano <st...@pearwood.info> wrote: > >> It's true what you're saying, but we consistently see bug reports > >> about people comparing ints or strings with is and complaining that > >> they work fine on cpython, but not on pypy. > > > > Then their code is buggy, not PyPy. But you know that :-) > > This is precisely what this thread is about: such "buggy" code that > uses "is" to compare two immutable objects. At this point, the > question is not "would it cause any trouble in existing programs to > say that "x is not y" when CPython in the same program says that "x is > y", because we know that the answer to that is "yes". > > We already found out a perfectly reasonable fix for "small" objects: two > equal ints are always "is"-identical and have the same id() in PyPy. > This is a nice way to solve the above problem. If anything it creates > the opposite problem: some code that works on PyPy might not work on > CPython. If PyPy becomes used enough, CPython will then have to care > about that too, and we'll end up with a well-defined definition of > "is" on immutable objects :-) > > But we're not (yet) using the same idea on *all* types of immutable > objects. So what we're concerned about now is whether it could be > implemented efficiently: the answer could be "yes if we forget about > strictly enforcing "x is y <=> id(x) == id(y)". So, the question: > although it's documented to be wrong, would it actually cause any > trouble to relax this requirement? > > > a = b = X # regardless of what X is > > mylist = [a, None] > > assert mylist[0] is a > > assert mylist[0] is b > > > > both assertions must pass, no matter what X is, whether mutable or > > immutable. > > I *think* that in this case the assertions cannot fail in PyPy either. > If X is a string, then we get as "mylist[0]" an object that is a > different W_StringObject but containing internally the same > RPython-level string, and as such (because we tweaked "is") they > compare "is"-identical. But that seems like a problem waiting to > happen: if in the future we're using a list strategy for a list > of single characters, then W_StringObjects containing single > characters will be rebuilt out of an RPython list of characters, and > not be "is"-identical under our current definition. > > In addition, the problem right now is about code like ``if x[5] is > '.': ...`` which happens to work as expected on CPython, but not on > PyPy. In PyPy's case the two strings x[5] and '.' are using different > RPython-level strings. > > > A bientôt, > > Armin. > _______________________________________________ > pypy-dev mailing list > pypy-dev@python.org > http://mail.python.org/mailman/listinfo/pypy-dev _______________________________________________ pypy-dev mailing list pypy-dev@python.org http://mail.python.org/mailman/listinfo/pypy-dev