In a message of Sun, 06 Mar 2011 10:59:55 +1100, "Steven D'Aprano" writes: <snip> >The more I think about this the more I agree with Fred Drake that we >should keep this simple. The documentation for the ``is`` operator is >not the place for a discussion of implementation-specific optimizations. > > The operator ``is`` tests whether the two operands are the > same object. ``is not`` tests that they are different objects. > >If we have to mention singletons here, and I don't think we do, then a >single example is enough: > > Singleton objects such as ``None`` are, by definition, > always the same object. > > > >-- >Steven
While the point is well taken that objects that are the same do not have to occupy the same memory location, and don't in PyPy, the problem with explaining the 'is' and 'is not' operator is explaining what 'is the same object' means. I think the greatest cause of confusion is the fact that Cpython interns the intergers. Thus: [GCC 4.4.5] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> x = 5 >>> x == 5 True >>> x is 5 True while: Python 2.5.2 (e503e483e9ac, Dec 21 2010, 12:02:29) [PyPy 1.4.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. And now for something completely different: ``dystopian and utopian chairs'' >>>> x = 5 >>>> x == 5 True >>>> x is 5 False ------------------ So maybe what we need to do is to explictly state that some implementations have chosen to represent objects which are equivalent as the exact same object, but that you should not rely on this behaviour because it is an implementation detail? Laura _______________________________________________ Doc-SIG maillist - Doc-SIG@python.org http://mail.python.org/mailman/listinfo/doc-sig