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?
--
INADA Naoki <songofacandy at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/doc-sig/attachments/20110305/ade04567/attachment.html>

Search Discussions

  • Steven D'Aprano at Mar 5, 2011 at 3:13 am

    INADA Naoki wrote:
    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
  • Fred Drake 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
  • INADA Naoki 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


    --
    INADA Naoki? <songofacandy at gmail.com>
  • Aahz 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
  • Laura Creighton 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
  • Elva Castaneda de Hall 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
  • Aahz 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
  • Steven D'Aprano 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.


    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
  • Laura Creighton 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>
    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
  • Fred Drake 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
  • Laura Creighton 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]
    Type "help", "copyright", "credits" or "license" for more information.
    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)
    Type "help", "copyright", "credits" or "license" for more information.
    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
  • Laura Creighton 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
    section is about at all.

    Laura
  • Nick Coghlan 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
  • Laura Creighton 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
  • Fred Drake 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 Navigation
viewthread | post
Discussion Overview
groupdoc-sig @
categoriespython
postedMar 5, '11 at 2:19a
activeMar 7, '11 at 4:12a
posts16
users7
websitepython.org

People

Translate

site design / logo © 2019 Grokbase