Pragmatics of the standard is() function

[candide]

In which cases should we use the is() function ? The is() function
compares identity of objects rather than values so I was wondering in
which circumstances comparing identities of objects is really vital.

Examining well reputated Python source code, I realize that is()
function is mainly used in the following set form :

spam is None

But how much "spam is None" is different from "spam == None" ?



is() function makes comparaison of (abstract representation of) adresses
of objects in memory. Comparing addresses of objects is a low level
feature performed by low level langages such as C but seldom needed in
high level languages like Python, isn'it ?

 

[Roy Smith]

In which cases should we use the is() function ? The is() function
compares identity of objects rather than values so I was wondering in
which circumstances comparing identities of objects is really vital.

Examining well reputated Python source code, I realize that is()
function is mainly used in the following set form :

spam is None

But how much "spam is None" is different from "spam == None" ?

It's the difference between *being* None, and being equal to None. For
example:

class Spam:
def __eq__(self, other):
return not other

spam = Spam()
print spam is None
print spam == None

When I run that, it prints:

False
True

In practice, when you compare something to None, you usually want the
"is" form. In cases where either would work (i.e. 99% of the time),
it's convention (and/or good practice) to use "is" because it more more
clearly expresses what it is that you're trying to do.

 

[Chris Angelico]

is() function makes comparaison of (abstract representation of) adresses of
objects in memory. Comparing addresses of objects is a low level feature
performed by low level langages such as C but seldom needed in high level
languages like Python, isn'it ?

You also want 'is' when you're testing for a singleton used as a default value:

DEFAULT = object()

def foo(arg1,arg2,arg3=DEFAULT):
if arg3 is DEFAULT: print("You gave me two args")


ChrisA

 

[Alexander Kapps]

On 26.11.2011 22:20, candide wrote:

You already got answers for the "is" vs. "==" difference. I'd like
to add the following.

In which cases should we use the is() function ?

"is" is not a function, It's an operator, just like == or +.

is() function makes comparaison of (abstract representation of)
adresses of objects in memory.

That's an implementation detail. CPython (and maybe others)
implement "is" in terms of memory addresses. Other implementations
might use an object ID number or whatever else.

 

[Steven D'Aprano]

In which cases should we use the is() function ? The is() function
compares identity of objects rather than values so I was wondering in
which circumstances comparing identities of objects is really vital.

`is` is not a function. It is a keyword and an operator.

You should always use `is` when you intend to test for object identity,
and never use `is` when you do not intend to test for object identity.
For example:

TASK: check whether a number is equal to 42.

# WRONG don't do this
if x is 42: ...
# RIGHT use equality instead
if x == 42: ...

Object identity is the wrong solution here, because you cannot control
whether Python will re-use the same object for every instance of 42, or
different objects each time.


TASK: check whether an object is a specific sentinel value, and no other
value, even if it happens to compare equal to the sentinel. The most
common sentinel is the singleton None.

# WRONG don't do this
if x == None: ...
# RIGHT use is instead
if x is None: ...


Use of equality is inappropriate, because it tests whether the object
compares equal to None. Although there are no built-ins that compare
equal to None, there could be any number of custom objects that do, and
so your code contains a bug: you intend to branch *only* on None, but
might branch on some other object by mistake.

Examining well reputated Python source code, I realize that is()
function is mainly used in the following set form :

spam is None

But how much "spam is None" is different from "spam == None" ?

Even if you can guarantee that your code base does not contain any object
which compares equal to None except for None itself (and how would you do
that? a full audit of every line of code in every library you use?), the
use of `is` should be preferred because it signals your intention much
better.

If your intention is to accept arbitrary objects which compare equal to
None, than by all means use == for your comparison. But normally the
intention is to accept None, and nothing else.

is() function makes comparaison of (abstract representation of) adresses
of objects in memory. Comparing addresses of objects is a low level
feature performed by low level langages such as C but seldom needed in
high level languages like Python, isn'it ?

That is correct. You probably should rarely use `is`. Apart from testing
for None, use of `is` should be rare.

 

[candide]

Thanks to all for your response.


Le 27/11/2011 00:01, Steven D'Aprano a écrit :

`is` is not a function. It is a keyword and an operator.

oops exponent 10 !! I have in mind the id() function, very close to the
is operator. An operator named "is" makes search of code snippets very
complicated because the verb "is" is always embedded in comments or
documentation.

Even if you can guarantee that your code base does not contain any object
which compares equal to None except for None itself (and how would you do
that? a full audit of every line of code in every library you use?), the
use of `is` should be preferred because it signals your intention much
better.

OK but tons of good code use "spam == None" ; for instance, many tests
files in Python official code. A random example (from
openshot/openshot/windows/MainGTK.py):

# ---------------------------------------------------------------

parent_name = item.parent
if parent_name == None:
match_iter = None

# Check for NO files
if mode == None and self.project.project_folder.items.__len__() == 0:
#switch to the detail view


if drop_track == None:
# keep old parent, if no track found


if self.new_clip_object == None:
self.item_detected = False

# ---------------------------------------------------------------

If your intention is to accept arbitrary objects which compare equal to
None, than by all means use == for your comparison. But normally the
intention is to accept None, and nothing else.

So, for the same reason, wouldn't it be better to use "if spam is True"
against to "if spam == True" (or better "if spam") ?

That is correct. You probably should rarely use `is`. Apart from testing
for None, use of `is` should be rare.

OK, thanks

 

[Chris Angelico]

So, for the same reason, wouldn't it be better to use "if spam is True"
against to "if spam == True"  (or better "if spam") ?

They're quite different. "if spam" will check the truthiness of spam -
it's equivalent to "if bool(spam) is True"; "if spam is True" checks
that it's actually a boolean. But I would recommend against the "==
True" form, as it's unclear which form you meant to use. (Others may
disagree.)

ChrisA

 

[Steven D'Aprano]

OK but tons of good code use "spam == None" ; for instance, many tests
files in Python official code. A random example (from
openshot/openshot/windows/MainGTK.py):

I don't know what openshot is, but I don't think it is "official" in the
sense of being in the Python standard library:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
ImportError: No module named openshot


But even if it were, the standard library is not written by superhuman
perfect gods, only by ordinary human beings who can make mistakes.
Comparing against None with == is not idiomatic Python, and is usually a
mistake. It rarely leads to obvious bugs, so it can survive in code
without notice for a long time.

So, for the same reason, wouldn't it be better to use "if spam is True"
against to "if spam == True" (or better "if spam") ?

No. Normally should just say "if spam" and allow Python to test the
truthiness of spam.

"if spam == True" is worse, because there are many truthy objects which
are not equal to True, e.g. 42, "norwegian blue", [1, 2, 3] are all
truthy objects that (almost always) should be accepted but will wrongly
be rejected.

"if spam is True" is even worse, because there are many truthy objects
that are not the True singleton. Old code, especially if it was written
before the introduction of bools in (I think) 2.1 or 2.2, often uses 1 as
the standard true-like value. To save typing, many people will still pass
1 or 0 as an argument when a bool is expected, which will then fail if
you test for identity.

The exception is if for some reason you actually care whether your flag
is the True object and absolutely nothing else. This violates Python's
preference for duck-typing and support for truthiness, but if you have a
good reason, go right ahead.

Suppose spam is already a bool. Then "if spam" is enough, since spam is a
bool. "if spam is True" is no more necessary than

if spam is True is True
if spam is True is True is True
if spam is True is True is True is True
if spam is True is True is True is True is True
if spam is True is True is True is True is True is True
# I never know when to stop...

The right place to stop is not to start. "if spam is True" is redundant.

And lastly, testing for identity against None is guaranteed by the
language: any implementation of Python must have None a singleton. But
True and False are not such a strong promise. A future version of Python,
or another implementation, might not bother to make True and False
singletons. (Doubletons?) Unlikely, but why make assumptions that you
don't need to?

 

[Jean-Michel Pichavant]

In which cases should we use the is() function ? The is() function
compares identity of objects rather than values so I was wondering in
which circumstances comparing identities of objects is really vital.

Examining well reputated Python source code, I realize that is()
function is mainly used in the following set form :

spam is None

But how much "spam is None" is different from "spam == None" ?



is() function makes comparaison of (abstract representation of)
adresses of objects in memory. Comparing addresses of objects is a low
level feature performed by low level langages such as C but seldom
needed in high level languages like Python, isn'it ?

I remember meeting a use case where testing identity is required, when
you are searching for an instance containing a specific object:

class Someone:
def __init__(self, name, car):
self.name = name
self.car = car

class Car:
def __init__(self, brand):
self.brand = brand
def __eq__(self, other):
return self.brand == other.brand

people = { 'bob':Someone('bob', Car('chrys')), 'cindy': Someone('cindy',
Car('Volk')), 'carlos':Someone('carlos', Car('Volk'))}
aCar = people['carlos'].car
print "people owning a Volk car", [ people[ppl].name for ppl in people
if people[ppl].car == Car('Volk')]
print "people owning Carlos's car", [ people[ppl].name for ppl in people
if people[ppl].car is aCar]

people owning a Volk car ['carlos', 'cindy']
people owning Carlos's car ['carlos']

JM

 

[Den]

That is correct. You probably should rarely use `is`. Apart from testing
for None, use of `is` should be rare.

With respect, I disagree with advice that the use of a language
construct should be rare. All constructs should be used
*appropriately*.

While in general a particular use of a Python construct may be rare,
if the programmer is involved deeply with that rare use, then it is
NOT rare to him/her. Thus, for a particular programmer, use of 'is'
may be quite frequent because the program they're working on requires
knowledge of object identity.

The same goes for global variables, by the way. While it's easy to
shoot yourself in the foot with global variables, that doesn't lead to
never-use-them. It leads to use-them-appropriately-and-carefully.

Sorry, you plucked a string of mine. One does not throw a tool out of
your tool box because it might be dangerous. Table saws are
incredibly dangerous, but in the hands of a skilled operator can be
competently and safely used to produce beautiful woodwork. To say
*never* use a table saw because it's dangerous is silly.

Language constructs are put there intentionally. Advice that they be
used *rarely* or *never* should *never* be given ((chuckle)). Just
learn what they are, learn how they work, learn what the consequences
of misuse can be (loss of a hand, in the case of a table saw), and use
them confidently when the circumstances make them the best choice of
tool to solve your problem.

To make a long comment short (too late!!) learn the differences
between 'is' and ==, and use them appropriately. When I was learning
Python, I found the two books by Mark Lutz to be filled with
information of such things as these.

D

 

[Ethan Furman]

With respect, I disagree with advice that the use of a language
construct should be rare. All constructs should be used
*appropriately*.

+1

~Ethan~

 

[alex23]

On Nov 26, 3:01 pm, Steven D'Aprano <steve

With respect, I disagree with advice that the use of a language
construct should be rare.  All constructs should be used
*appropriately*.

Steven didn't say it _shouldn't_ be used, only that it it should be
_rarely_ used. General consensus would be that that is the most
appropriate use of 'is'.

Value comparisons are _far_ more common in Python than identity
comparisons, the ubiquitous None notwithstanding.

But for your general point, I totally agree. I feel the same way about
the ternary syntax, boolean defaults for conditionals etc

 

[Steven D'Aprano]

With respect, I disagree with advice that the use of a language
construct should be rare. All constructs should be used
*appropriately*.

And if those appropriate conditions are rare, then the use of the
appropriate construct should also be rare. Since it is rare to need to
care about identity, use of `is` should be rare too.

This is mostly descriptive statement rather than a prescriptive one: it
is a fact that use of `is` is much less common than use of ==, and even
more so if you disregard the obvious case of "x is None".

I am however being a little prescriptive: if somebody thinks they need to
care about identity, chances are good -- but not certain -- that they're
mistaken. In code that gives you the choice between writing `is` and ==,
it is usually, but not often, a bug to write `is`. The proof of this is
that in actual, existing code, if you swapped == and `is`, most of the
code would stop working correctly.

On the other hand if you actually do need to care about identity, then go
for it. I'm not saying that caring about identity should be prohibited,
only that in practice it is uncommon that you will.

While in general a particular use of a Python construct may be rare, if
the programmer is involved deeply with that rare use, then it is NOT
rare to him/her.

Regardless of how common brain surgery might be to a brain surgeon, it is
rare in general. That's all I'm saying. If you happen to work for a data
recovery centre, then pulling the disk platter out of a hard disk drive
might be commonplace to you, nevertheless pulling platters out of disks
is vanishingly rare: out of tens of thousands of HDDs, perhaps only a few
dozen will be sent to a recover centre at all.

[...]

Sorry, you plucked a string of mine. One does not throw a tool out of
your tool box because it might be dangerous. Table saws are incredibly
dangerous, but in the hands of a skilled operator can be competently and
safely used to produce beautiful woodwork. To say *never* use a table
saw because it's dangerous is silly.

Fortunately, I didn't say "never".

In the case of `is`, one shouldn't avoid using `is` because it is
dangerous, but merely because it is the wrong thing to use. In the same
way, the average programmer will rarely need to use the math.sinh and
math.cosh functions, not because they are bad, evil, or dangerous, but
because they are used for specialist purposes that most coders would
never care about. Hell, most coders rarely use the standard trigonometric
functions sin and cos, let alone the hyperbolic versions! This is not a
value judgement.

If I, in a misplaced sense of egalitarianism ("Emancipation for maths
functions! Right on brothers!") decided to use sinh instead of sin
because they looked and sounded similar, my code would almost certain be
buggy. Likewise if I decided to use `is` instead of == because in English
they have similar meanings, my code would probably be buggy too.

Sorry to belabour the point, but we're in violent agreement here <wink>

 

[Den]

With respect, I disagree with advice that the use of a language
construct should be rare.  All constructs should be used
*appropriately*.

And if those appropriate conditions are rare, then the use of the
appropriate construct should also be rare. Since it is rare to need to
care about identity, use of `is` should be rare too.

This is mostly descriptive statement rather than a prescriptive one: it
is a fact that use of `is` is much less common than use of ==, and even
more so if you disregard the obvious case of "x is None".

I am however being a little prescriptive: if somebody thinks they need to
care about identity, chances are good -- but not certain -- that they're
mistaken. In code that gives you the choice between writing `is` and ==,
it is usually, but not often, a bug to write `is`. The proof of this is
that in actual, existing code, if you swapped == and `is`, most of the
code would stop working correctly.

On the other hand if you actually do need to care about identity, then go
for it. I'm not saying that caring about identity should be prohibited,
only that in practice it is uncommon that you will.

While in general a particular use of a Python construct may be rare, if
the programmer is involved deeply with that rare use, then it is NOT
rare to him/her.

Regardless of how common brain surgery might be to a brain surgeon, it is
rare in general. That's all I'm saying. If you happen to work for a data
recovery centre, then pulling the disk platter out of a hard disk drive
might be commonplace to you, nevertheless pulling platters out of disks
is vanishingly rare: out of tens of thousands of HDDs, perhaps only a few
dozen will be sent to a recover centre at all.

[...]

Sorry, you plucked a string of mine.  One does not throw a tool out of
your tool box because it might be dangerous.  Table saws are incredibly
dangerous, but in the hands of a skilled operator can be competently and
safely used to produce beautiful woodwork.  To say *never* use a table
saw because it's dangerous is silly.

Fortunately, I didn't say "never".

In the case of `is`, one shouldn't avoid using `is` because it is
dangerous, but merely because it is the wrong thing to use. In the same
way, the average programmer will rarely need to use the math.sinh and
math.cosh functions, not because they are bad, evil, or dangerous, but
because they are used for specialist purposes that most coders would
never care about. Hell, most coders rarely use the standard trigonometric
functions sin and cos, let alone the hyperbolic versions! This is not a
value judgement.

If I, in a misplaced sense of egalitarianism ("Emancipation for maths
functions! Right on brothers!") decided to use sinh instead of sin
because they looked and sounded similar, my code would almost certain be
buggy. Likewise if I decided to use `is` instead of == because in English
they have similar meanings, my code would probably be buggy too.

Sorry to belabour the point, but we're in violent agreement here <wink>

((laugh)) Yes, I believe we are.

D