FAQ
In
http://docs.python.org/py3k/tutorial/datastructures.html#comparing-sequences-and-other-types
,

The operators is and is notcompare whether two objects are really the same
object;
this only matters for mutable objects like lists.

I think this notation may confuse readers of the tutorial. For example, pep8
recommands
using is operator for immutable singleton objects like None.

Shall we remove letter part?
--
-------------- next part --------------
An HTML attachment was scrubbed...

## Search Discussions

•  at Mar 5, 2011 at 3:13 am ⇧

In
http://docs.python.org/py3k/tutorial/datastructures.html#comparing-sequences-and-other-types
,

The operators is and is notcompare whether two objects are really the same
object;
this only matters for mutable objects like lists.

I think this notation may confuse readers of the tutorial. For example, pep8
recommands
using is operator for immutable singleton objects like None.

Shall we remove letter part?
Rather than completely remove it, I would reword it:

The operators is and is not compare whether two objects are really the
same object; this usually only matters for mutable objects like lists,
or for testing against singletons like None.

--
Steven
•  at Mar 5, 2011 at 4:14 am ⇧

On Fri, Mar 4, 2011 at 10:13 PM, Steven D'Aprano wrote:
The operators is and is not compare whether two objects are really the same
object; this usually only matters for mutable objects like lists, or for
testing against singletons like None.
I think having text about mutability here is confusing. Consider:
x = []
a = x,
b = x,
Here, a and b are different immutable objects, though they'll always
be equal. "is" and "==" will produce different results; whether that
matters is context-dependent. "==" will always return the *same*
result as the list in x is mutated.

Further:
c = [],
d = [],
c and d are different objects, and their equality will vary as the
contained lists are mutated.

a, b, c and d are all immutable.

So let's not condition the explanation with vague hints about when
testing identity makes sense. I expect it will lead to more confusion
than it will avoid.

? -Fred

--
Fred L. Drake, Jr.? ? <fdrake at acm.org>
"A storm broke loose in my mind."? --Albert Einstein
•  at Mar 5, 2011 at 5:30 am ⇧
If detailed description is needed, my suggesting is:

"""
The operators?``is``?and?``is?not`` compare whether two objects are
really the same object.
Note that immutable objects having same value and type may be unified
for efficiency.
For example, ``'spam' is 'spam'`` is either ``True`` or ``False`` depending on
Python implementation.
Especially, singleton objects like ``True``, ``False``, ``None`` are always same
object when thier type and value is same.
"""

This description may have to been splitted to separate paragraph.
On Sat, Mar 5, 2011 at 1:14 PM, Fred Drake wrote:
On Fri, Mar 4, 2011 at 10:13 PM, Steven D'Aprano wrote:
The operators is and is not compare whether two objects are really the same
object; this usually only matters for mutable objects like lists, or for
testing against singletons like None.
I think having text about mutability here is confusing. ?Consider:

? ?>>> x = []
? ?>>> a = x,
? ?>>> b = x,

Here, a and b are different immutable objects, though they'll always
be equal. ?"is" and "==" will produce different results; whether that
matters is context-dependent. ?"==" will always return the *same*
result as the list in x is mutated.

Further:

? ?>>> c = [],
? ?>>> d = [],

c and d are different objects, and their equality will vary as the
contained lists are mutated.

a, b, c and d are all immutable.

So let's not condition the explanation with vague hints about when
testing identity makes sense. ?I expect it will lead to more confusion
than it will avoid.

? -Fred

--
Fred L. Drake, Jr.? ? <fdrake at acm.org>
"A storm broke loose in my mind."? --Albert Einstein
_______________________________________________
Doc-SIG maillist ?- ?Doc-SIG at python.org
http://mail.python.org/mailman/listinfo/doc-sig

--
•  at Mar 5, 2011 at 5:06 pm ⇧

On Sat, Mar 05, 2011, INADA Naoki wrote:
If detailed description is needed, my suggesting is:

"""
The operators ``is`` and ``is not`` compare whether two objects
are really the same object. Note that immutable objects having
same value and type may be unified for efficiency. For example,
``'spam' is 'spam'`` is either ``True`` or ``False`` depending on
Python implementation. Especially, singleton objects like ``True``,
``False``, ``None`` are always same object when thier type and value
is same.
"""
+1 -- here's my rewrite for a bit more clarity:

The operators ``is`` and ``is not`` compare whether two objects are
really the same object (have the same memory location). Immutable
objects with the same value and type may be cached to the same object for
efficiency. For example, ``'spam' is 'spam'`` is either ``True`` or
``False`` depending on Python implementation. Singleton objects
(``True``, ``False``, ``None``) are always the same object.
--
Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/

"Programming language design is not a rational science. Most reasoning
about it is at best rationalization of gut feelings, and at worst plain
wrong." --GvR, python-ideas, 2009-03-01
•  at Mar 5, 2011 at 7:12 pm ⇧

In a message of Sat, 05 Mar 2011 09:06:22 PST, Aahz writes:
+1 -- here's my rewrite for a bit more clarity:

The operators ``is`` and ``is not`` compare whether two objects are
really the same object (have the same memory location). Immutable
objects with the same value and type may be cached to the same object for
efficiency. For example, ``'spam' is 'spam'`` is either ``True`` or
``False`` depending on Python implementation. Singleton objects
(``True``, ``False``, ``None``) are always the same object.
I like Aahz's version.
Laura
•  at Mar 5, 2011 at 7:16 pm ⇧
Hello!
I am not sure how I ended up with a subscription to this virtual
conversation. I am not even sure where to go to unsubscribe.

Rest assured I have no clue what is being discussed here. ; > )

Can someone tell me the website URL I can go to unsubscribe?

Thanks, e
On Mar 5, 2011, at 11:12 AM, Laura Creighton wrote:

In a message of Sat, 05 Mar 2011 09:06:22 PST, Aahz writes:
+1 -- here's my rewrite for a bit more clarity:

The operators ``is`` and ``is not`` compare whether two objects are
really the same object (have the same memory location). Immutable
objects with the same value and type may be cached to the same
object for
efficiency. For example, ``'spam' is 'spam'`` is either ``True`` or
``False`` depending on Python implementation. Singleton objects
(``True``, ``False``, ``None``) are always the same object.
I like Aahz's version.
Laura

_______________________________________________
Doc-SIG maillist - Doc-SIG at python.org
http://mail.python.org/mailman/listinfo/doc-sig
•  at Mar 5, 2011 at 7:21 pm ⇧

On Sat, Mar 05, 2011, Elva Castaneda de Hall wrote:
Hello!
I am not sure how I ended up with a subscription to this virtual
conversation. I am not even sure where to go to unsubscribe.

Rest assured I have no clue what is being discussed here. ; > )

Can someone tell me the website URL I can go to unsubscribe?
Look at the bottom of this message. ;-)
--
Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/

"Programming language design is not a rational science. Most reasoning
about it is at best rationalization of gut feelings, and at worst plain
wrong." --GvR, python-ideas, 2009-03-01
•  at Mar 5, 2011 at 11:59 pm ⇧

Aahz wrote:

The operators ``is`` and ``is not`` compare whether two objects are
really the same object (have the same memory location). Immutable
objects with the same value and type may be cached to the same object for
efficiency. For example, ``'spam' is 'spam'`` is either ``True`` or
``False`` depending on Python implementation. Singleton objects
(``True``, ``False``, ``None``) are always the same object.

Please remove the bit about the same memory location. That is an
implementation detail which may be true for CPython, it may even be true
for any sensible implementation of Python, but it's surely not a
necessary condition for any language calling itself Python. I don't
think it adds any clarity, since "same object" is a more intuitive
concept than memory location (even non-programmers understand what it
means to say that "my car" and "the car parked in the driveway" are the
same object). And memory location is not something that Python the
language exposes to the caller. Implementations with moving garbage
collectors, such as PyPy and (I think) Jython, may move objects. All in
all, I believe that Python's docs should stay as far away from any
discussion of memory addresses as possible.

It might be obvious to English speakers that ``is`` and ``is not`` do
the opposite, but as it stands above, the documentation suggests that
they are two different ways of writing the same thing.

None, True and False are not the only singletons in Python, but the
above gives the false impression of an exhaustive list.

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
•  at Mar 6, 2011 at 12:45 am ⇧
In a message of Sun, 06 Mar 2011 10:59:55 +1100, "Steven D'Aprano" writes:
<snip>
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
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
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
•  at Mar 7, 2011 at 4:09 am ⇧

On Sat, Mar 5, 2011 at 7:45 PM, Laura Creighton wrote:
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?
That still seems too complicated. Pointing out that equality does not
imply identity, regardless of type, should be sufficient for the
purpose of describing "is".

? -Fred

--
Fred L. Drake, Jr.? ? <fdrake at acm.org>
"A storm broke loose in my mind."? --Albert Einstein
•  at Mar 6, 2011 at 11:08 pm ⇧
I've been doing more thinking, and I think the problem is more deeply
rooted than this.

From the original doc:
The operators is and is not compare whether two objects are really the same
object;
this only matters for mutable objects like lists.
This is actually wrong. If x is y, then you _aren't_ comparing two
objects, you are comparing one object with itself, and that is the
whole point. You are comparing two names, and seeing if they are
bound to the same object. What I really want to tell the perplexed
to do is read: http://effbot.org/zone/python-objects.htm However:

Given that this is in the section on comparing sequences and other
types:

The operators ``is`` and ``is not`` test for object identity. If two
different names are bound to the same object, then they compare the
same: ``x is y`` .
v = [1,2,3]
w = v
v is w
True
v.append(4)
v
[1, 2, 3, 4]
w
[1, 2, 3, 4]

Confusion arises because implementors are free to cache immutable objects
with the same value and type to the same object for reasons of efficiency.

[PyPy 1.4.1]
w = 1
y = 1
w is y
False

Python 2.6.6 #(I don't have a 3.x around , I assume it works the same way)
w = 1
y = 1
w is y # this might surprise you
True

Testing the object identity of unmutable objects with the ``is``
or ``is not`` operators is rarely something you want to do, because the
result is implementation dependent.

Singleton objects such as ``True``, ``False``, and ``None`` are always
the same object. The canonical way to test whether an object is
a singleton is to test for object identity, not equality. So
if x is None:
... do something ...

not
if x == None:
... do something ...

--------------
I think this will fix the confusion, but maybe it belongs someplace
other than the comparing sequence section.
http://docs.python.org/py3k/tutorial/datastructures.html#comparing-sequences-and-other-types
•  at Mar 6, 2011 at 11:28 pm ⇧
In a message of Mon, 07 Mar 2011 00:08:38 +0100, Laura Creighton writes:
<snip>

oops, that one escaped before I was done.

The other point was that I wondered about the section title itself.
5.8. Comparing Sequences and Other Types

This reads as if we are comparing types, when that is not what this

Laura
•  at Mar 7, 2011 at 12:30 am ⇧

On Mon, Mar 7, 2011 at 9:08 AM, Laura Creighton wrote:
Singleton objects such as ``True``, ``False``, and ``None`` are always
the same object. ?The canonical way to test whether an object is
a singleton is to test for object identity, not equality. ?So
if x is None:
? ?... do something ...

not
if x == None:
? ?... do something ...
Careful with that - "if x is True:" and "if x is False:" (along with
s/is/==/) are almost always the wrong thing to do, but a reader could
easily generalise the above to cover those two cases as well.

Cheers,
Nick.

--
Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia
•  at Mar 7, 2011 at 1:29 am ⇧

In a message of Mon, 07 Mar 2011 10:30:08 +1000, Nick Coghlan writes:
On Mon, Mar 7, 2011 at 9:08 AM, Laura Creighton wrote:
Singleton objects such as ``True``, ``False``, and ``None`` are always
the same object. The canonical way to test whether an object is
a singleton is to test for object identity, not equality. So:
if x is None:
... do something ...

not
if x == None:
... do something ...
Careful with that - "if x is True:" and "if x is False:" (along with
s/is/==/) are almost always the wrong thing to do, but a reader could
easily generalise the above to cover those two cases as well.

Cheers,
Nick.
Good point. Indeed, that may be where people who write code like that
get the idea. I've always wondered.

Ok.

Change to:

Testing the object identity of unmutable objects with the ``is``
or ``is not`` operators is rarely something you want to do, because the
result is implementation dependent. But the canonical way to test
whether an object is None is to test for object identity, not equality.

so
if x is None: # this is how we write it
... do something ...

not
if x == None: # don't do this.
... do something ...

-----------
I figure that the fact that None is a singleton is not actually relevant
to this.

Laura
•  at Mar 7, 2011 at 4:12 am ⇧

On Sun, Mar 6, 2011 at 8:29 PM, Laura Creighton wrote:
I figure that the fact that None is a singleton is not actually relevant
to this.
It's important because Python promises that None is a singleton at the
language level, rather than the implementation level. That's
different than using cached values of small integers, since that's a
runtime efficiency issue (and therefore implementation specific).

That's essential to the recommended practice of testing for None using
"is" rather than "=="; it's irrelevant to the general description of
"is".

? -Fred

--
Fred L. Drake, Jr.? ? <fdrake at acm.org>
"A storm broke loose in my mind."? --Albert Einstein

## Related Discussions

Discussion Overview
 group doc-sig categories python posted Mar 5, '11 at 2:19a active Mar 7, '11 at 4:12a posts 16 users 7 website python.org

### 7 users in discussion

Content

People

Support

Translate

site design / logo © 2019 Grokbase