In article ,
Laszlo Nagy wrote:
>
>All right, I see your point now. So can we say, that the id function can
>be used to tell if two mutable objects are different as long as they are
>both alive during the comparison?
Yes
--
Aahz (a...@pythoncraft.com) <*> http://www.pythoncr
Mel wrote:
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)
This use of `is` is fine.
For my fears to come tr
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 circumstan
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` work
None, True, False, integers and strings are not mutable. The only time
the id is the "same" between two objects is if they are the identical
two objects.
I'm aware of that. ;-)
CPython just (as a performance optimization) re-uses the same objects
sometimes even if people think they're usi
Christian Heimes írta:
Chris Rebert wrote:
The built-ins aren't mutable, and the singletons are each immutable
and/or unique; so in no case do objects that are both different and
mutable have the same ID.
Correct, the fact allows you to write code like "type(egg) is str" to
check if an
The built-ins aren't mutable, and the singletons are each immutable
and/or unique; so in no case do objects that are both different and
mutable have the same ID.
I know. :-)
Although I have no idea how it is that `id({}) == id({})` as a prior
posted showed; FWIW, I can't manage to reproduce
Mel wrote:
> 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.
'is' has important use cases but it's not trivial to use if you leave
t
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
>
Tim Chase wrote:
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
> It's believable if id({}) does the following:
>
> 1. Construct an empty dict
> 2. Take the id of the dict
> 3. Reduce the reference-count on the now-unneeded dict.
>
> It's not too hard for the second empty dict to get allocated in the same
> memory that the first one (now dereferenced and de
Chris Rebert wrote:
> Although I have no idea how it is that `id({}) == id({})` as a prior
> posted showed; FWIW, I can't manage to reproduce that outcome.
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 informa
On Wed, Oct 14, 2009 at 4:19 PM, Chris Rebert wrote:
> Although I have no idea how it is that `id({}) == id({})` as a prior
> posted showed; FWIW, I can't manage to reproduce that outcome.
>
With Python 2.5.1 on MacOS X, I can; it looks like there's an optimization
in there where its 'saving' di
Chris Rebert wrote:
> The built-ins aren't mutable, and the singletons are each immutable
> and/or unique; so in no case do objects that are both different and
> mutable have the same ID.
Correct, the fact allows you to write code like "type(egg) is str" to
check if an object *is* an instance of s
On Wed, Oct 14, 2009 at 1:37 PM, Laszlo Nagy wrote:
>
> Andre Engels schrieb:
>>
>>>
>>> None, True, False, NotImplemented are guaranteed to be singletons, all
>> builtin types and exceptions can be considered as singletons, too.
>>
>>
> I thought that different mutable objects always have differ
On Wed, Oct 14, 2009 at 1:37 PM, Laszlo Nagy wrote:
>> Andre Engels schrieb:
>>> What is going on is that a few objects that are often used, in
>>> particular the small (how small is small depends on the
>>> implementation) integers, are 'preloaded'. When one of these is then
>>> referred to, a ne
Andre Engels schrieb:
What is going on is that a few objects that are often used, in
particular the small (how small is small depends on the
implementation) integers, are 'preloaded'. When one of these is then
referred to, a new object is not created, but the pre-defined object
is used. 10 i
Andre Engels schrieb:
> What is going on is that a few objects that are often used, in
> particular the small (how small is small depends on the
> implementation) integers, are 'preloaded'. When one of these is then
> referred to, a new object is not created, but the pre-defined object
> is used. 1
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
What is going on is that a few objects that are often used, in
particular the small (how small is small depends on the
implementation) integers, are 'preloaded'. When one of these is then
referred to, a new object is not created, but the pre-defined object
is used. 10 is apparently a preloaded cons
raffaele ponzini schrieb:
> Dear all,
> I have a question concerning the output of the id() function.
> In particular since is should:
> ""
> Return the identity of an object. This is guaranteed to be unique among
> simultaneously existing objects. (Hint: it's the object's memory address.)
> ""
>
Dear all,
I have a question concerning the output of the id() function.
In particular since is should:
""
Return the identity of an object. This is guaranteed to be unique among
simultaneously existing objects. (Hint: it's the object's memory address.)
""
i expect that for two differnt objects it
Dear all,
I have a question concerning the output of the id() function.
In particular since is should:
""
Return the identity of an object. This is guaranteed to be unique among
simultaneously existing objects. (Hint: it's the object's memory address.)
""
i expect that for two differnt objects it
23 matches
Mail list logo
