Re: What's the address for?
On Wed, Feb 20, 2019 at 5:28 AM Grant Edwards wrote: > > On 2019-02-19, Chris Angelico wrote: > > On Wed, Feb 20, 2019 at 3:23 AM Grant Edwards > > wrote: > > > >> Those object _may_ each have different identies. Is it required that > >> they do? If an assignment is done on name referring to an object with > >> no other references, would it be allowed that the "old" object is > >> destroyed and its ID reused for a new object being created by the RHS > >> of the assignment? > >> > >> Admittedly, that would be a rather odd way to do things. One would > >> expect that first the RHS is evaluated (perhaps creating a new > >> object), then the name is rebound. > > > > Correct, the RHS is evaluated first. So the old object is still > > around (important for statements like "x = x.lower()"). > > Not doing the unbinding until after the RHS evaluation is also > important for preventing surprises due to exceptions raised while the > RHS is evaluated. One would reasonably expect that if that happens > the original binding of the name on the LHS is unchanged. > > Dunno if that's actually specified anywhere... > It is, yes: https://docs.python.org/3/reference/expressions.html#evaluation-order ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: What's the address for?
On 2019-02-19, Chris Angelico wrote: > On Wed, Feb 20, 2019 at 3:23 AM Grant Edwards > wrote: > >> Those object _may_ each have different identies. Is it required that >> they do? If an assignment is done on name referring to an object with >> no other references, would it be allowed that the "old" object is >> destroyed and its ID reused for a new object being created by the RHS >> of the assignment? >> >> Admittedly, that would be a rather odd way to do things. One would >> expect that first the RHS is evaluated (perhaps creating a new >> object), then the name is rebound. > > Correct, the RHS is evaluated first. So the old object is still > around (important for statements like "x = x.lower()"). Not doing the unbinding until after the RHS evaluation is also important for preventing surprises due to exceptions raised while the RHS is evaluated. One would reasonably expect that if that happens the original binding of the name on the LHS is unchanged. Dunno if that's actually specified anywhere... -- Grant Edwards grant.b.edwardsYow! Someone in DAYTON, at Ohio is selling USED gmail.comCARPETS to a SERBO-CROATIAN -- https://mail.python.org/mailman/listinfo/python-list
Re: What's the address for?
On Wed, Feb 20, 2019 at 3:23 AM Grant Edwards wrote: > > On 2019-02-19, Ben Finney wrote: > > >> On the implementation I am using, the ID changes if I do this: > > > > You are creating new objects and binding the name ‘a’ to different > > objects in succession. Those different objects will each have different > > identities. > > Those object _may_ each have different identies. Is it required that > they do? If an assignment is done on name referring to an object with > no other references, would it be allowed that the "old" object is > destroyed and its ID reused for a new object being created by the RHS > of the assignment? > > Admittedly, that would be a rather odd way to do things. One would > expect that first the RHS is evaluated (perhaps creating a new > object), then the name is rebound. > Correct, the RHS is evaluated first. So the old object is still around (important for statements like "x = x.lower()"). ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: What's the address for?
On 2019-02-19, Ben Finney wrote: >> On the implementation I am using, the ID changes if I do this: > > You are creating new objects and binding the name ‘a’ to different > objects in succession. Those different objects will each have different > identities. Those object _may_ each have different identies. Is it required that they do? If an assignment is done on name referring to an object with no other references, would it be allowed that the "old" object is destroyed and its ID reused for a new object being created by the RHS of the assignment? Admittedly, that would be a rather odd way to do things. One would expect that first the RHS is evaluated (perhaps creating a new object), then the name is rebound. -- Grant Edwards grant.b.edwardsYow! I wish I was a at sex-starved manicurist gmail.comfound dead in the Bronx!! -- https://mail.python.org/mailman/listinfo/python-list
Re: What's the address for?
Stefan Ram wrote: What's so important about the (presumed) address of a function that it is shown on every stringification of each function? Its value isn't important at all. It's just a way of distinguishing different objects in debugging output. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: What's the address for?
"Avi Gross" writes: > I hear that [the ‘id(foo)’ return value] is implementation dependent. > But are there any requirements on the implementation that allow it to > have meaning? The requirements are that `id(foo)` should satisfy the documented API for that function https://docs.python.org/3/library/functions.html#id>: Return the “identity” of an object. This is an integer which is guaranteed to be unique and constant for this object during its lifetime. Two objects with non-overlapping lifetimes may have the same `id()` value. > I mean is the ID guaranteed to be unique and not reused within a > session? No. The identity of an object is guaranteed to be unique only during the lifetime of that object. This implies that *outside* the lifetime of that object (before it exists; after it is destroyed) the same value is allowed to be the identity of some other object. > If two things concurrently show the same ID, are they the same in some > way? Yes, querying the identity of two references concurrently will return the same identity value only if those two references refer to the same object. That is the essential meaning of an object identity: you can compare it with some other identity value and see whether that came from the same object. Other than object identity, there is pretty much no guarantee (and hence almost no purpose for the value you get from ‘id(foo)’). That is useful enough, of course. > On the implementation I am using, the ID changes if I do this: You are creating new objects and binding the name ‘a’ to different objects in succession. Those different objects will each have different identities. > It looks like the ID of "a" can change depending on its contents. That's because a name is not a container, it is a reference. Names don't know *anything* about the object; they have no type, no identity, nothing except the ability to refer to some object at a particular point in time. > So I decided to do what maybe should be done first. Find some > documentation! Yes (especially the documentation of the function you're using, ‘id’). Also helpful: Learn the actual behaviour of references in Python. They do not behave like “variables” in some other languages (I avoid talking about Python “variables” at all, for this reason). References are not containers, and thinking of them that way will frequently lead you to the wrong conclusion. https://nedbatchelder.com/text/names1.html> -- \ “Theology is the effort to explain the unknowable in terms of | `\ the not worth knowing.” —Henry L. Mencken | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: What's the address for?
On Tue, Feb 19, 2019 at 7:04 AM Avi Gross wrote: > How about functions? > > Even more confusing: > > >>> def a(): pass > > >>> def b(): pass > > >>> id(a), id(b) > (13123280, 13201816) > >>> b=a > >>> id(a), id(b) > (13123280, 13123280) > >>> def a(): return True > > >>> id(a), id(b) > (13201816, 13123280) > > The above shows that making two independent (albeit otherwise minimally > identical) functions makes two different id and copying one to the other > makes them the same but then changing one gets back the same ID reused! Actually, this part isn't explained by the id() docs. To understand this, you need to go back to something even more basic: the meaning of assignment. You did not copy one to the other. You simply changed name bindings. Here. Read. https://nedbatchelder.com/text/names1.html ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: What's the address for?
On Tue, Feb 19, 2019 at 7:04 AM Avi Gross wrote: > > Alister wrote about the meaning of the id number often displayed about a > python object: > > > it is the internal id of the function - Not necessarily an address, that > is an implementation detail. > > > it is not intended for use within a program & has (almost) no practical > use. > > I hear that it is implementation dependent. But are there any requirements > on the implementation that allow it to have meaning? I mean is the ID > guaranteed to be unique and not reused within a session? If two things > concurrently show the same ID, are they the same in some way? Have you considered reading the docs? https://docs.python.org/3/library/functions.html#id """Return the “identity” of an object. This is an integer which is guaranteed to be unique and constant for this object during its lifetime. Two objects with non-overlapping lifetimes may have the same id() value.""" I'm fairly sure that answers all your questions. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
RE: What's the address for?
Alister wrote about the meaning of the id number often displayed about a
python object:
> it is the internal id of the function - Not necessarily an address, that
is an implementation detail.
> it is not intended for use within a program & has (almost) no practical
use.
I hear that it is implementation dependent. But are there any requirements
on the implementation that allow it to have meaning? I mean is the ID
guaranteed to be unique and not reused within a session? If two things
concurrently show the same ID, are they the same in some way?
On the implementation I am using, the ID changes if I do this:
>>> a = 1
>>> id(a)
271178896
>>> a = 2
>>> id(a)
271178912
>>> a = 1
>>> id(a)
271178896
It looks like the ID of "a" can change depending on its contents. But when I
set it back to the first content, I get the same ID.
Again, on MY IMPLEMENTATION, I did an experiment to see if the constants 1
and 2 share that ID.
>>> id(1)
271178896
>>> id(2)
271178912
It seems they do. So I tried setting variable b several ways:
>>> b = 1
>>> id(b)
271178896
>>> b = a
>>> id(b), id(a)
(271178896, 271178896)
>>> a = 2
>>> (271178896, 271178896)
(271178896, 271178896)
So it does seem in this artificial case of looking at something easily
cached like an integer, that ID has these qualities.
I tried using complex and the results are a bit complex:
>>> import math
>>> a = complex("1+2j")
>>> a
(1+2j)
>>> id(a)
48066432
>>> id(complex("1+2j"))
55084360
>>> b = complex("1+2j")
>>> id(b)
55084360
>>> a = b
>>> id(a)
55084360
>>> a = complex("1+2j")
>>> id(a)
48066432
>>> c = complex(1,2)
>>> id(c)
55086880
We seem to go between two values although I am not sure why.
How about functions?
Even more confusing:
>>> def a(): pass
>>> def b(): pass
>>> id(a), id(b)
(13123280, 13201816)
>>> b=a
>>> id(a), id(b)
(13123280, 13123280)
>>> def a(): return True
>>> id(a), id(b)
(13201816, 13123280)
The above shows that making two independent (albeit otherwise minimally
identical) functions makes two different id and copying one to the other
makes them the same but then changing one gets back the same ID reused!
So, I would be hesitant about assigning much meaning to an ID. It might be
useful within an implementation when using a debugger but perhaps not much
more.
So I decided to do what maybe should be done first. Find some documentation!
If what I read is accurate, given the source, it sounds like for Cpython an
ID may be a memory address and the guarantee is that once an ID is assigned
to something it will not be reassigned to something else as long as the
object remains in effect. Well, I assume that means that anything else set
to be the same as the original as in "a = b" will share that ID. Once an
object is gone, the ID can be reused.
This may help understand some of the above results especially since memory
management may not rapidly get rid of something. I concur that there is
often not much point in using id() or even its cousin is.
-Original Message-
From: Python-list On
Behalf Of Alister via Python-list
Sent: Monday, February 18, 2019 8:29 AM
To: python-list@python.org
Subject: Re: What's the address for?
On Mon, 18 Feb 2019 11:59:18 +, Stefan Ram wrote:
> When one prints a function, one might get something like:
>
>
>
> . The participants of my basic course asked me what the address is
> for. I did not know.
>
> What's so important about the (presumed) address of a function that it
> is shown on every stringification of each function?
it is the internal id of the function - Not necessarily an address, that is
an implementation detail.
it is not intended for use within a program & has (almost) no practical use.
--
Microsoft Zen - Become one with the blue screen.
-- From a Slashdot.org post
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
Re: What's the address for?
On Mon, 18 Feb 2019 11:59:18 +, Stefan Ram wrote: > When one prints a function, one might get something like: > > > > . The participants of my basic course asked me what the address is > for. I did not know. > > What's so important about the (presumed) address of a function that it > is shown on every stringification of each function? it is the internal id of the function - Not necessarily an address, that is an implementation detail. it is not intended for use within a program & has (almost) no practical use. -- Microsoft Zen - Become one with the blue screen. -- From a Slashdot.org post -- https://mail.python.org/mailman/listinfo/python-list
