Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #108254 > unrolled thread
| Started by | Anthony Papillion <anthony@cajuntechie.org> |
|---|---|
| First post | 2016-05-07 01:36 -0500 |
| Last post | 2016-05-07 20:05 +1000 |
| Articles | 2 — 2 participants |
Back to article view | Back to comp.lang.python
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Why do these statements evaluate the way they do? Anthony Papillion <anthony@cajuntechie.org> - 2016-05-07 01:36 -0500
Re: Why do these statements evaluate the way they do? Steven D'Aprano <steve@pearwood.info> - 2016-05-07 20:05 +1000
| From | Anthony Papillion <anthony@cajuntechie.org> |
|---|---|
| Date | 2016-05-07 01:36 -0500 |
| Subject | Why do these statements evaluate the way they do? |
| Message-ID | <mailman.446.1462603041.32212.python-list@python.org> |
I'm trying to figure out why the following statements evaluate the way they do and I'm not grasping it for some reason. I'm hoping someone can help me. 40+2 is 42 #evaluates to True But 2**32 is 2**32 #evaluates to False This is an example taken from a Microsoft blog on the topic. They say the reason is because the return is based on identity and not value but, to me, these statements are fairly equal. Can someone clue me in? Anthony -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
[toc] | [next] | [standalone]
| From | Steven D'Aprano <steve@pearwood.info> |
|---|---|
| Date | 2016-05-07 20:05 +1000 |
| Message-ID | <572dbddd$0$1620$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #108254 |
On Sat, 7 May 2016 04:36 pm, Anthony Papillion wrote:
> I'm trying to figure out why the following statements evaluate the way
> they do and I'm not grasping it for some reason. I'm hoping someone can
> help me.
>
> 40+2 is 42 #evaluates to True
> But
> 2**32 is 2**32 #evaluates to False
That is not a guarantee of the language, it is an implementation detail.
The only language guarantee is that:
40 + 2 == 42
which MUST be true. But the Python interpreter has a choice here:
- it can create *two* distinct int objects with value 42;
- or it can cache the int object and re-use it.
In the first case, `40 + 2 is 42` will return False. In the second case, it
will return True.
Remember that `is` does not test for equality, it checks for object
identity, namely, "are the two objects one and the same object?"
The standard Python interpreter caches "small integers". The definition
of "small" depends on the version, but 42 is included, and 2**32 is not. So
you may find that
40 + 2 is 42
re-uses the same cached object and returns True, but
2**32 is 2**32
creates a new int object each time and returns False.
The lesson here is:
(1) ** NEVER ** use `is` to test for equality. The `is` operator is not a
funny well of spelling == it is a completely different operator that tests
for object identity.
(2) You cannot rely on Python object caches, as that is implementation and
version dependent. It is an optimization, to speed up some arithmetic at
the expense of using a little more memory.
(3) Almost the only acceptable use for `is` is to test for the singleton
object None. (There are other uses, but they are unusual and testing for
None is common. Always write:
if obj is None: ...
rather than:
if obj == None: ...
But for (nearly) everything else, always use == equality.
--
Steven
[toc] | [prev] | [standalone]
Back to top | Article view | comp.lang.python
csiph-web