Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   Python (http://www.velocityreviews.com/forums/f43-python.html)
-   -   Re: id( ) function question (http://www.velocityreviews.com/forums/t701543-re-id-function-question.html)

Tim Chase 10-14-2009 11:21 AM

Re: id( ) function question
 
> But if I chose as a value another number (a big one, let say 1e10) I
> get what I will expect also in the case of the chose of the integer 10
> showed above:
>>>> a=1e10
>>>> d=1e10
>>>> d is a

> False
>>>> id(a)

> 11388984
>>>> id(d)

> 11388920


CPython has the option to cache frequently used items, and does
so for a small range of ints. It's not guaranteed behavior (or a
guaranteed range) so you shouldn't rely on it, but it's an
efficiency thing. In my current version, it looks like it's ints
from -5 to 256. YMMV

In general, if you're using "is" (and not comparing with None) or
id(), you're doing it wrong unless you already know the
peculiarities of Python's identity implementations.

-tkc



Mel 10-15-2009 12:30 PM

Re: id( ) function question
 
Erik Max Francis wrote:
> Tim Chase wrote:
>> In general, if you're using "is" (and not comparing with None) or id(),
>> you're doing it wrong unless you already know the peculiarities of
>> Python's identity implementations.


> Right. Another way to do look at it is that if you're curious about
> what the value of `id` is or how the `is` operator works, the short
> version is, don't worry about them, as you won't be using them.


As Python has evolved the semantics have got richer, and the implementation
has got trickier with proxy objects and wrapped functions and more.
Whatever use there was for `is` in ordinary code is vanishing.

Even a straight-up assignment can fool:

Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41)
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class A(object):

.... def __init__ (self):
.... self.mangler = self.method1
.... def method1 (self):
.... return id (self) ^ 30103
.... def is_mangled (self):
.... return self.mangler is self.method1
....
>>> a=A()
>>> a.is_mangled()

False

I fully understand that there's an excellent reason for that -- I wouldn't
have it any other way. Also note that, in the same example

>>> a.mangler == a.method1

True


My poster-child use of `is` is a MUDD game where

`reference1_to_player is reference2_to_player`

, if True, means that both refer to the same in-game player. Even that
might not last.

> I'm really rather surprised at the number of questions about them.
> They're really something one does not need to worry about.


Particularly to the newbie, `is` and `id` look like they ought to be good
for *something*. You have to know a lot about Python internals to know how
little they mean.

Maybe the docs should have some kind of "Debugging and Introspection"
dungeon that they could be thrown into.


Mel.


Mel 10-16-2009 01:32 PM

Re: id( ) function question
 
Erik Max Francis wrote:

> Mel wrote:
>> My poster-child use of `is` is a MUDD game where
>>
>> `reference1_to_player is reference2_to_player`
>>
>> , if True, means that both refer to the same in-game player. Even that
>> might not last.

>
> Well, that usage is fine; I can't see any circumstances under which it
> might change. `is` works when you really _do_ want to check whether two
> objects are the same.

[ ... ]

True, I don't see that exact expression going wrong. The actual poster,
trimmed for that post, used to go:

def broadcast (self, message):
for p in players:
if p is not self:
p.send (message)

For my fears to come true, the for/in interface might be changed to do some
important piece of bookkeeping that needed the yielded objects to be
wrapped. I don't know what that would be. So far, Python is only changing
such things when it's well worth it.

You could imagine a really intrusive debugging tool trying such things, at
the cost of un-debugging programs that relied on `id` or `is`.

Mel.



All times are GMT. The time now is 04:42 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.