curiosity about the nature of identity (in python)

[James Stroud]

Hello all,

What /is/ identity in python? For example, we can always count on

py> None is None
True

But I have noticed that this works for strings:

py> "none" is "none"
True

and, for example, integers:

py> 42 is 42
True

And I have noticed that this works for equivalent expressions:

py> 42 is (40 + 2)
True

So, I'm guessing that the integer 42, or the string "none" is cached
somewhere and python looks to see if it is in the cache when evaluating
'is'. My guess is supported with this test:

py> id(42)
149679044
py> id(40+2)
149679044
py> id(7*6)
149679044

So, I guess my question is to what extent is this equivalency
implementation dependent? Is this equivalency a requirement for a
legitimate python implementation? Won't these checks slow down
evaluation of 'is' considerably? Does '==' ever fall back and use 'is'
(or 'id') for evaluation?

Just curious.

James


--
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095

http://www.jamesstroud.com/

 

[Grant Edwards]

Now what about this:

134745616

id of an object is unique *for the lifetime of this object*. Nothing
prevents it from being reused later.

Indeed. Since in CPython, it's the address of a C language
data structure, if IDs didn't get re-used, then the virtual
memory size of any long-running Python program would grow
without bound. The working set would grow more slowly that the
total virtual size, but it would still be problematic.

 

[Bruno Desthuilliers]

James Stroud a écrit :

Hello all,

What /is/ identity in python?

A unique identifier associated with each and every object in the
process. What exactly is this identifier is left to the implementation -
FWIW and IIRC, CPython uses the memory address of the C 'object'
datastructure.

For example, we can always count on

py> None is None
True

Yes. None is a singleton.

But I have noticed that this works for strings:

py> "none" is "none"
True
>
and, for example, integers:

py> 42 is 42
True

This is an implementation detail of CPython - which does some caching,
and is by no way specified by the language. You should *never* rely on
this. FWIW, try:

a = 3900000
b = 3900000
a is b

And I have noticed that this works for equivalent expressions:

py> 42 is (40 + 2)
True

So, I'm guessing that the integer 42, or the string "none" is cached
somewhere

Bingo !-)

and python looks to see if it is in the cache when evaluating
'is'.

I don't think the evaluation of 'is' as anything to do with this.

My guess is supported with this test:

py> id(42)
149679044
py> id(40+2)
149679044
py> id(7*6)
149679044

Now what about this:
134745616

id of an object is unique *for the lifetime of this object*. Nothing
prevents it from being reused later.

So, I guess my question is to what extent is this equivalency
implementation dependent?

cf above

Is this equivalency a requirement for a
legitimate python implementation?

cf above

Won't these checks slow down
evaluation of 'is' considerably?

I really doubt that comparing memory addresses could be slow...

Does '==' ever fall back and use 'is'
(or 'id') for evaluation?

Seems so :
True