In article mailman.1455.1255622678.2807.python-l...@python.org,
Laszlo Nagy gand...@shopzeus.com 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
--
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
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
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
the
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
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
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
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`
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
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.)
i expect
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
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
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 is
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
On Wed, Oct 14, 2009 at 1:37 PM, Laszlo Nagy gand...@shopzeus.com 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
On Wed, Oct 14, 2009 at 1:37 PM, Laszlo Nagy gand...@shopzeus.com 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
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 str.
On Wed, Oct 14, 2009 at 4:19 PM, Chris Rebert c...@rebertia.com 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
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 information.
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
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
22 matches
Mail list logo
