On Fri, 25 Aug 2017 12:42 am, Stefan Ram wrote:
> i = 0
> while True: print( f"{ i }:{ id( i )}" ); i = i + 1
>
> This loop prints increasing ids while i is less than
> 257, and then it starts to print alternating ids.
Try running it under Jython or IronPython.
Try running it starting with
On Thu, 24 Aug 2017 11:21:27 -0400, Ned Batchelder wrote:
> On 8/24/17 10:42 AM, Stefan Ram wrote:
>> i = 0 while True: print( f"{ i }:{ id( i )}" ); i = i + 1
>>
>> This loop prints increasing ids while i is less than 257, and then it
>> starts to print alternating ids.
>>
>> So this seems
On 8/24/17 10:42 AM, Stefan Ram wrote:
> i = 0
> while True: print( f"{ i }:{ id( i )}" ); i = i + 1
>
> This loop prints increasing ids while i is less than
> 257, and then it starts to print alternating ids.
>
> So this seems to indicate that temporary objects are
> created for large inte
Terry Reedy :
> On 2/22/2015 4:25 PM, Marko Rauhamaa wrote:
>> This is a true statement:
>>
>> If X is Y, then id(X) == id(Y).
>>
>> However, this is generally not a true statement:
>>
>> If X is Y, then id(X) is id(Y).
>
> If X and Y exist at the *same time*, then (X is Y) == (id(X) is id
On 02/22/2015 10:02 PM, Terry Reedy wrote:
On 2/22/2015 4:25 PM, Marko Rauhamaa wrote:
LJ :
id(b[0])
4582
[...]
id(b[2])
4582
Please correct me if I am wrong, but according to this b[2] and b[0]
are the same object. Now,
b[0] is b[2]
False
This is a true statement:
If
On 2/22/2015 12:53 PM, LJ wrote:
Hi everyone. Quick question here. Lets suppose if have the
following numpy array:
b=np.array([[0]*2]*3)
and then:
id(b[0])
4582
id(b[1])
45857512
id(b[2])
4582
Please correct me if I am wrong,
You are, as other explained
> but according to th
On 2/22/2015 4:25 PM, Marko Rauhamaa wrote:
LJ :
id(b[0])
4582
[...]
id(b[2])
4582
Please correct me if I am wrong, but according to this b[2] and b[0]
are the same object. Now,
b[0] is b[2]
False
This is a true statement:
If X is Y, then id(X) == id(Y).
However, this
LJ wrote:
> Hi everyone. Quick question here. Lets suppose if have the following numpy
> array:
>
> b=np.array([[0]*2]*3)
>
> and then:
>
id(b[0])
> 4582
id(b[1])
> 45857512
id(b[2])
> 4582
>
> Please correct me if I am wrong, but according to this b[2] and b[0] are
> th
On Mon, Feb 23, 2015 at 8:25 AM, Marko Rauhamaa wrote:
> This is a true statement:
>
>If X is Y, then id(X) == id(Y).
>
> However, this is generally not a true statement:
>
>If X is Y, then id(X) is id(Y).
Irrelevant, because the identities of equal integers didn't come into this.
ChrisA
LJ :
id(b[0])
> 4582
[...]
id(b[2])
> 4582
>
> Please correct me if I am wrong, but according to this b[2] and b[0]
> are the same object. Now,
>
b[0] is b[2]
> False
This is a true statement:
If X is Y, then id(X) == id(Y).
However, this is generally not a true statem
Ooops, I missed the numpy, so I thought that it was the contents
of the array that was causing the problem. My very bad. Apologies.
Laura
--
https://mail.python.org/mailman/listinfo/python-list
On 02/22/2015 09:53 AM, LJ wrote:
Hi everyone. Quick question here. Lets suppose if have the following numpy
array:
b=np.array([[0]*2]*3)
and then:
id(b[0])
4582
id(b[1])
45857512
id(b[2])
4582
Please correct me if I am wrong, but according to this b[2] and b[0] are the
same o
On Mon, Feb 23, 2015 at 5:13 AM, Laura Creighton wrote:
> In a message of Sun, 22 Feb 2015 09:53:33 -0800, LJ writes:
>>Hi everyone. Quick question here. Lets suppose if have the following numpy
>>array:
>>
>>b=np.array([[0]*2]*3)
>>
>>and then:
>>
> id(b[0])
>>4582
> id(b[1])
>>45857
In a message of Sun, 22 Feb 2015 09:53:33 -0800, LJ writes:
>Hi everyone. Quick question here. Lets suppose if have the following numpy
>array:
>
>b=np.array([[0]*2]*3)
>
>and then:
>
id(b[0])
>4582
id(b[1])
>45857512
id(b[2])
>4582
>
>Please correct me if I am wrong, but ac
In article ,
Cameron Simpson wrote:
> The "is" test is more direct and less subject to iffiness because the longer
> expression using id() leaves more scope/time for things to change, and of
> course "id" itself can be rebound to something weird.
Not to mention that Python is case-sensitive a
Ben Finney writes:
> Dan Stromberg writes:
> > Are the following two expressions the same?
[…]
>
> It depends what you mean by “the same”.
My apologies, I mis-read the question. My answers were for a different
question (one you didn't ask). Please ignore that.
--
\ “If you ever reach to
On 27Oct2014 00:41, MRAB wrote:
On 2014-10-27 00:24, Ethan Furman wrote:
On 10/26/2014 05:23 PM, Ethan Furman wrote:
On 10/26/2014 05:12 PM, Dan Stromberg wrote:
Are the following two expressions the same?
x is y
Id(x) == id(y)
?
Listen to MRAB, ignore me.
That is all.
Well, apart of J
On Sun, 26 Oct 2014 17:12:29 -0700, Dan Stromberg wrote:
> Are the following two expressions the same?
>
> x is y
>
> Id(x) == id(y)
No, although if "Id" and "id" were the same function, they might be
equivalent in some cases.
--
Denis McMahon, denismfmcma...@gmail.com
--
https://mail.pyth
Dan Stromberg writes:
> Are the following two expressions the same?
>
> x is y
>
> Id(x) == id(y)
It depends what you mean by “the same”.
Do they give the same result? Sometimes yes, sometimes no. It depends on
what the types of the values are.
Do they express the same intent? Always no. The f
On 2014-10-27 00:24, Ethan Furman wrote:
On 10/26/2014 05:23 PM, Ethan Furman wrote:
On 10/26/2014 05:12 PM, Dan Stromberg wrote:
Are the following two expressions the same?
x is y
Id(x) == id(y)
?
Listen to MRAB, ignore me.
That is all.
Well, apart of Joshua's qualifications, that is!
On 10/26/2014 05:12 PM, Dan Stromberg wrote:
Are the following two expressions the same?
x is y
Id(x) == id(y)
?
Nope. If the value if `id(x)` is not interned, then the two value could be different objects that still represent the
same value.
--
~Ethan~
--
https://mail.python.org/mailman
On 10/26/2014 05:23 PM, Ethan Furman wrote:
On 10/26/2014 05:12 PM, Dan Stromberg wrote:
Are the following two expressions the same?
x is y
Id(x) == id(y)
?
Listen to MRAB, ignore me.
That is all.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
On 27 October 2014 00:12, Dan Stromberg wrote:
> Are the following two expressions the same?
>
> x is y
>
> Id(x) == id(y)
Much of the time, but not all the time. The obvious exception is if
"id" is redefined, but that one's kind of boring. The real thing to
watch out for is if the object that "x
On 2014-10-27 00:12, Dan Stromberg wrote:
Are the following two expressions the same?
x is y
Id(x) == id(y)
?
Yes.
I ported some Java code to Python, and it was using Java's idea of
equality (via ==) in some places. Right now, I have a suite of unit
tests working using the second expressi
On Feb 9, 5:06 am, Chris Angelico wrote:
> On Thu, Feb 9, 2012 at 2:48 PM, Emeka wrote:
>
> > My question is why is it that the id of Boo.daf is different from daf's hex
> > value in the above dict?
>
>
> daf is not a function, it's a special object for an unbound method.
http://wiki.python.org
On 2/8/2012 10:48 PM, Emeka wrote:
class Boo(object):
def __init__(self , moon, sun):
self.moon = moon
self.sun = sun
def daf(self):
return self.sun + self.moon
def ball(self):
return self.sun * self.moon
print Boo.__dict__
{'__module__': '__main__',
On Thu, Feb 9, 2012 at 2:48 PM, Emeka wrote:
> I am trying to see if I could get more of Python without being insane.
Oh, I thought insanity was a prerequisite... anyway.
> print Boo.__dict__
>
> {'__module__': '__main__', 'ball': , 'daf':
> , '__dict__ ..}
>
> print hex(id(Boo.daf))
> 0x27
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.)
> ""
>
On Apr 5, 9:30 pm, Steve Holden <[EMAIL PROTECTED]> wrote:
>
> In fact all you can in truth say is that
>
>a is b --> a == b
>
You can't even guarantee that.
>>> inf = 1e1000
>>> nan = inf / inf
>>> nan is nan
True
>>> nan == nan
False
--
http://mail.python.org/mailman/listinfo/python-list
Gabriel Genellina wrote:
> En Thu, 03 Apr 2008 19:27:47 -0300, <[EMAIL PROTECTED]> escribió:
>
>> Hi all,
>>
>> I've been playing around with the identity function id() for different
>> types of objects, and I think I understand its behaviour when it comes
>> to objects like lists and tuples in wh
En Thu, 03 Apr 2008 19:27:47 -0300, <[EMAIL PROTECTED]> escribió:
> Hi all,
>
> I've been playing around with the identity function id() for different
> types of objects, and I think I understand its behaviour when it comes
> to objects like lists and tuples in which case an assignment r2 = r1
> (
> Hi all,
>
> I've been playing around with the identity function id() for different
> types of objects, and I think I understand its behaviour when it comes
> to objects like lists and tuples in which case an assignment r2 = r1
> (r1 refers to an existing object) creates an alias r2 that refers to
[EMAIL PROTECTED] wrote:
> 1) Which of the above behaviours are reliable? For example, does a1 =
> a2 for ints and strings always imply that a1 is a2?
No.
> 2) From the programmer's perspective, are ids of ints, floats and
> string of any practical significance at all (since these types are
> im
On Apr 3, 11:27 pm, [EMAIL PROTECTED] wrote:
> Hi all,
>
> I've been playing around with the identity function id() for different
> types of objects, and I think I understand its behaviour when it comes
> to objects like lists and tuples in which case an assignment r2 = r1
> (r1 refers to an existi
54 matches
Mail list logo
