Re: [Python-Dev] Need discussion for a PR about memory and objects

2018-11-20 Thread Jeff Allen 

On 20/11/2018 00:14, Chris Barker via Python-Dev wrote:
On Mon, Nov 19, 2018 at 1:41 AM Antoine Pitrou > wrote:


I'd rather keep the reference to memory addressing than start
doing car
analogies in the reference documentation.


I agree -- and any of the car analogies will probably be only valid in 
some jurisdictions, anyway.


I think being a bit more explicit about what properties an ID has, and 
how the id() function works, and we may not need an anlogy at all, 
it's not that difficult a concept. And methions that in c_python the 
id is (currently) the memory address is a good idea for those that 
will wonder about it, and if there is enough explanation, folks that 
don't know about memory addresses will not get confused.

...

I suggest something like the following:

"""
Every object has an identity, a type and a value. An object’s identity 
uniquely identifies the object. It will remain the same as long as 
that object exists. No two different objects will have the same id at 
the same time, but the same id may be re-used for future objects once 
one has been deleted. The ‘is’ operator compares the identity of two 
objects; the id() function returns an integer representing its 
identity. ``id(object_a) == id(object_b)`` if and only if they are the 
same object.


**CPython implementation detail:** For CPython, id(x) is the memory 
address where x is stored.

"""
I agree that readers of a language reference should be able to manage 
without the analogies.


I want to suggest that identity and id() are different things.

The notion of identity in Python is what we access in phrases like "two 
different objects" and "the same object" in the text above. For me it 
defies definition, although one may make statements about it. A new 
object, wherever stored, is identically different from all objects 
preceding it.


Any Python has to implement the concept of identity in order to refer, 
without confusion, to objects in structures and bound by names. In 
practice, Python need only identify an object while the object exists in 
the interpreter, and the object exists as long as something refers to it 
in this way. To this extent, the identifier in the implementation need 
not be unique for all time.


The id() function returns an integer approximating this second idea. 
There is no mechanism to reach the object itself from the result, since 
it does not keep the object in existence, and worse, it may now be the 
id of a different object. In defining id(), I think it is confusing to 
imply that this number *is* the identity of the object that provided it.


Jeff Allen
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Need discussion for a PR about memory and objects

2018-11-19 Thread Steven D'Aprano 
Responding to a few points out of order.

On Mon, Nov 19, 2018 at 04:14:03PM -0800, Chris Barker via Python-Dev wrote:

> I think being a bit more explicit about what properties an ID has, and how
> the id() function works, and we may not need an anlogy at all, it's not
> that difficult a concept.
[...]

> I suggest something like the following:
> 
> """
> Every object has an identity, a type and a value. An object’s identity
> uniquely identifies the object. It will remain the same as long as that
> object exists. No two different objects will have the same id at the same
> time, but the same id may be re-used for future objects once one has been
> deleted. The ‘is’ operator compares the identity of two objects; the id()
> function returns an integer representing its identity. ``id(object_a) ==
> id(object_b)`` if and only if they are the same object.

That looks good to me. However...

> And methions that in c_python the id is
> (currently) the memory address is a good idea for those that will wonder
> about it, and if there is enough explanation, folks that don't know about
> memory addresses will not get confused.

I don't think that the problem is that people don't understand the 
"memory address as ID" implementation. I think the problem is people who 
can't separate the implementation from the interface. jThere is a small 
minority of developers, not just beginners, who insist that 
(paraphrasing) "the id() function returns the object's memory address", 
which leads others asking how to dereference the ID to get access to the 
object.

E.g. I recently saw somebody on Reddit asking how to delete an object 
given its address in Python.

I admit that this is just a minor point of confusion. We're not exactly 
innundated with dozens of requests for pointer arithmetic and PEEK/POKE 
commands *wink* but if we can reduce the confusion even further, that 
would be nice. We've had 20+ years of telling people that the C memory 
address of the object is an implementation detail, and some folks still 
don't get it.

I'd like to that we reduce the emphasis on memory address in the docs. 
Perhaps all the way to zero :-)

As you quoted, we currently we have a note in the docs that says:

  **CPython implementation detail:** For CPython, id(x) is the memory 
  address where x is stored.

I'd like to banish that note to the C-API docs (I'm not sure where), the 
FAQs (which apparently nobody ever reads *wink*) or perhaps just link to 
the source and let those who care read if for themselves.

Instead, I'd like a more comprehensive comment directly in the 
description of id, something like:

   There are no guarantees made for the ID number except as above.
   For example, Python implementations are known to take IDs from a 
   sequential series of integers (1, 2, 3, ...), or use arbitrary 
   implementation-defined values (263459012). Any such integer is
   permitted so long as the ID is constant and unique for the 
   lifespan of the object.



-- 
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Need discussion for a PR about memory and objects

2018-11-19 Thread Glenn Linderman 

On 11/19/2018 4:14 PM, Chris Barker via Python-Dev wrote:
On Mon, Nov 19, 2018 at 1:41 AM Antoine Pitrou > wrote:


I'd rather keep the reference to memory addressing than start
doing car
analogies in the reference documentation.


I agree -- and any of the car analogies will probably be only valid in 
some jurisdictions, anyway.


I think being a bit more explicit about what properties an ID has, and 
how the id() function works, and we may not need an anlogy at all, 
it's not that difficult a concept. And methions that in c_python the 
id is (currently) the memory address is a good idea for those that 
will wonder about it, and if there is enough explanation, folks that 
don't know about memory addresses will not get confused.


This is what's in the docs now (3.8.0a0):

"""
Every object has an identity, a type and a value. An object’s identity 
never changes once it has been created; you may think of it as the 
object’s address in memory. The ‘is’ operator compares the identity of 
two objects; the id() function returns an integer representing its 
identity.


**CPython implementation detail:** For CPython, id(x) is the memory 
address where x is stored.

"""

I suggest something like the following:

"""
Every object has an identity, a type and a value. An object’s identity 
uniquely identifies the object. It will remain the same as long as 
that object exists. No two different objects will have the same id at 
the same time, but the same id may be re-used for future objects once 
one has been deleted. The ‘is’ operator compares the identity of two 
objects; the id() function returns an integer representing its 
identity. ``id(object_a) == id(object_b)`` if and only if they are the 
same object.


**CPython implementation detail:** For CPython, id(x) is the memory 
address where x is stored.

"""



Well re-worded in my opinion.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Need discussion for a PR about memory and objects

2018-11-19 Thread Chris Barker via Python-Dev 
On Mon, Nov 19, 2018 at 1:41 AM Antoine Pitrou  wrote:

> I'd rather keep the reference to memory addressing than start doing car
> analogies in the reference documentation.
>

I agree -- and any of the car analogies will probably be only valid in some
jurisdictions, anyway.

I think being a bit more explicit about what properties an ID has, and how
the id() function works, and we may not need an anlogy at all, it's not
that difficult a concept. And methions that in c_python the id is
(currently) the memory address is a good idea for those that will wonder
about it, and if there is enough explanation, folks that don't know about
memory addresses will not get confused.

This is what's in the docs now (3.8.0a0):

"""
Every object has an identity, a type and a value. An object’s identity
never changes once it has been created; you may think of it as the object’s
address in memory. The ‘is’ operator compares the identity of two objects;
the id() function returns an integer representing its identity.

**CPython implementation detail:** For CPython, id(x) is the memory address
where x is stored.
"""

I suggest something like the following:

"""
Every object has an identity, a type and a value. An object’s identity
uniquely identifies the object. It will remain the same as long as that
object exists. No two different objects will have the same id at the same
time, but the same id may be re-used for future objects once one has been
deleted. The ‘is’ operator compares the identity of two objects; the id()
function returns an integer representing its identity. ``id(object_a) ==
id(object_b)`` if and only if they are the same object.

**CPython implementation detail:** For CPython, id(x) is the memory address
where x is stored.
"""

-CHB

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Need discussion for a PR about memory and objects

2018-11-19 Thread Antoine Pitrou 
On Sun, 18 Nov 2018 22:32:35 +1000
Nick Coghlan  wrote:
> 
> Chris's initial suggestion was to use "license number" or "social
> security number" (i.e. numbers governments assign to people), but I'm
> thinking a better comparison might be to vehicle registration numbers,
> since that analogy can be extended to the type and value
> characteristics in a fairly straightforward way:
> 
> - the object identity is like the registration number or license plate
> (unique within the particular system of registering vehicles, but not
> unique across systems, and may sometimes be transferred to a new
> vehicle after the old one is destroyed)
> - the object type is like the make and model (e.g. a 2007 Toyota
> Corolla Ascent Sedan)
> - the object value is a specific car (e.g. "that white Corolla over
> there with 89000 km on the odometer")
> 
> On the other hand, we're talking about the language reference here,
> not the tutorial, and understanding memory addressing seems like a
> reasonable assumed pre-requisite in that context.

I'd rather keep the reference to memory addressing than start doing car
analogies in the reference documentation.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Need discussion for a PR about memory and objects

2018-11-18 Thread Greg Ewing 

Chris Angelico wrote:

Licence plate numbers do get reused.


And they can change, e.g. if you get a personalised plate.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Need discussion for a PR about memory and objects

2018-11-18 Thread Greg Ewing 

Nick Coghlan wrote:

- the object identity is like the registration number or license plate
(unique within the particular system of registering vehicles, but not
unique across systems, and may sometimes be transferred to a new
vehicle after the old one is destroyed)
- the object type is like the make and model (e.g. a 2007 Toyota
Corolla Ascent Sedan)
- the object value is a specific car (e.g. "that white Corolla over
there with 89000 km on the odometer")


A bit confusing, because "that white Corolla over there" is referring
to its identity.

--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Need discussion for a PR about memory and > objects

2018-11-18 Thread Hugh Fisher 
> Date: Sun, 18 Nov 2018 22:32:35 +1000
> From: Nick Coghlan 
> To: "Steven D'Aprano" 
> Cc: python-dev 
> Subject: Re: [Python-Dev] Need discussion for a PR about memory and
> objects

[  munch background ]
>
> Chris's initial suggestion was to use "license number" or "social
> security number" (i.e. numbers governments assign to people), but I'm
> thinking a better comparison might be to vehicle registration numbers,
> since that analogy can be extended to the type and value
> characteristics in a fairly straightforward way:
>
> - the object identity is like the registration number or license plate
> (unique within the particular system of registering vehicles, but not
> unique across systems, and may sometimes be transferred to a new
> vehicle after the old one is destroyed)
> - the object type is like the make and model (e.g. a 2007 Toyota
> Corolla Ascent Sedan)
> - the object value is a specific car (e.g. "that white Corolla over
> there with 89000 km on the odometer")
>
> On the other hand, we're talking about the language reference here,
> not the tutorial, and understanding memory addressing seems like a
> reasonable assumed pre-requisite in that context.

"Handle" has been used since the 1980s among Macintosh and
Win32 programmers as "unique identifier of some object but isn't
the memory address". The usage within those APIs seems to
match what's being proposed for the new Python C API, in that
programmers used functions to ask "what type are you?" "what
value do you have?" but couldn't, or at least shouldn't, rely on
actual memory layout.

I suggest that for the language reference, use the license plate
or registration analogy to introduce "handle" and after that use
handle throughout. It's short, distinctive, and either will match
up with what the programmer already knows or won't clash if
or when they encounter handles elsewhere.

-- 

cheers,
Hugh Fisher
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Need discussion for a PR about memory and objects

2018-11-18 Thread Jeff Allen 

I found this (very good) summary ended in a surprising conclusion.

On 18/11/2018 12:32, Nick Coghlan wrote:

On Sun, 4 Nov 2018 at 23:33, Steven D'Aprano  wrote:

On Sun, Nov 04, 2018 at 11:43:50AM +0100, Stephane Wirtel wrote:

In this PR [https://github.com/python/cpython/pull/3382] "Remove reference
to
address from the docs, as it only causes confusion", opened by Chris
Angelico, there is a discussion about the right term to use for the
address of an object in memory.

Why do we need to refer to the address of objects in memory?

...
Chris's initial suggestion was to use "license number" or "social
security number" (i.e. numbers governments assign to people), but I'm
thinking a better comparison might be to vehicle registration numbers,
...
On the other hand, we're talking about the language reference here,
not the tutorial, and understanding memory addressing seems like a
reasonable assumed pre-requisite in that context.

Cheers,
Nick.
It is a good point that this is in the language reference, not a 
tutorial. Could we not expect readers of that to be prepared for a 
notion of object identity as the abstraction of what we mean by "the 
same object" vs "a distinct object"? If it were necessary to be explicit 
about what Python means by it, one could unpack the idea by its 
properties: distinct names may be given to the same object 
(is-operator); distinct objects may have the same value (==-operator); 
an object may change in value (if allowed by its type) while keeping its 
identity.


And then there is the id() function. That is an imperfect reflection of 
the identity. id() guarantees that for a given object (identity) it will 
always return the same integer during the life of that object, and a 
different integer for any distinct object (distinct identity) with an 
overlapping lifetime. We note that, in an implementation of Python where 
objects are fixed in memory for life, a conformant id() may return the 
object's address.


Jeff Allen




___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Need discussion for a PR about memory and objects

2018-11-18 Thread Chris Angelico 
On Mon, Nov 19, 2018 at 6:01 AM Richard Damon  wrote:
> One issue with things like vehicle registration numbers is that the VIN
> of a vehicle is really a UUID, it is globally unique no other vehicle
> will every have that same ID number, and people may not think of the
> fact that some other ID numbers, like the SSN do get reused. Since the
> Python Object Identities can get reused after the object goes away, the
> analogy really needs to keep that clear, and not give the other extreme
> of a false impression that the ID won't get reused after the object goes
> away.

Licence plate numbers do get reused.

ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Need discussion for a PR about memory and objects

2018-11-18 Thread Richard Damon 
On 11/18/18 7:32 AM, Nick Coghlan wrote:
> On Sun, 4 Nov 2018 at 23:33, Steven D'Aprano  wrote:
>> On Sun, Nov 04, 2018 at 11:43:50AM +0100, Stephane Wirtel wrote:
>>> In this PR [https://github.com/python/cpython/pull/3382] "Remove reference
>>> to
>>> address from the docs, as it only causes confusion", opened by Chris
>>> Angelico, there is a discussion about the right term to use for the
>>> address of an object in memory.
>> Why do we need to refer to the address of objects in memory?
> Following up on this discussion from a couple of weeks ago, note that
> Stephane misstated Chris's question/proposal from the PR slightly.
>
> The context is that the data model documentation for objects currently
> describes them as having an identity, a type, and a value, and then
> uses "address in memory" as an analogy for the properties that the
> object identity has (i.e. only one object can have a given identifier
> at any particular point in time, but identifiers can be re-used over
> time as objects are created and destroyed).
>
> That analogy is problematic, since it encourages the "object
> identities are memory addresses" mindset that happens to be true in
> CPython, but isn't true for Python implementations in general, and
> also isn't helpful for folks that have never learned a lower level
> language where you're manipulating pointers directly.
>
> However, simply removing the analogy entirely leaves that paragraph in
> the documentation feeling incomplete, so it would be valuable to
> replace it with a different real world analogy that will make sense to
> a broad audience.
>
> Chris's initial suggestion was to use "license number" or "social
> security number" (i.e. numbers governments assign to people), but I'm
> thinking a better comparison might be to vehicle registration numbers,
> since that analogy can be extended to the type and value
> characteristics in a fairly straightforward way:
>
> - the object identity is like the registration number or license plate
> (unique within the particular system of registering vehicles, but not
> unique across systems, and may sometimes be transferred to a new
> vehicle after the old one is destroyed)
> - the object type is like the make and model (e.g. a 2007 Toyota
> Corolla Ascent Sedan)
> - the object value is a specific car (e.g. "that white Corolla over
> there with 89000 km on the odometer")
>
> On the other hand, we're talking about the language reference here,
> not the tutorial, and understanding memory addressing seems like a
> reasonable assumed pre-requisite in that context.
>
> Cheers,
> Nick.

One issue with things like vehicle registration numbers is that the VIN
of a vehicle is really a UUID, it is globally unique no other vehicle
will every have that same ID number, and people may not think of the
fact that some other ID numbers, like the SSN do get reused. Since the
Python Object Identities can get reused after the object goes away, the
analogy really needs to keep that clear, and not give the other extreme
of a false impression that the ID won't get reused after the object goes
away.

-- 
Richard Damon

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Need discussion for a PR about memory and objects

2018-11-18 Thread Nick Coghlan 
On Sun, 4 Nov 2018 at 23:33, Steven D'Aprano  wrote:
>
> On Sun, Nov 04, 2018 at 11:43:50AM +0100, Stephane Wirtel wrote:
> > In this PR [https://github.com/python/cpython/pull/3382] "Remove reference
> > to
> > address from the docs, as it only causes confusion", opened by Chris
> > Angelico, there is a discussion about the right term to use for the
> > address of an object in memory.
>
> Why do we need to refer to the address of objects in memory?

Following up on this discussion from a couple of weeks ago, note that
Stephane misstated Chris's question/proposal from the PR slightly.

The context is that the data model documentation for objects currently
describes them as having an identity, a type, and a value, and then
uses "address in memory" as an analogy for the properties that the
object identity has (i.e. only one object can have a given identifier
at any particular point in time, but identifiers can be re-used over
time as objects are created and destroyed).

That analogy is problematic, since it encourages the "object
identities are memory addresses" mindset that happens to be true in
CPython, but isn't true for Python implementations in general, and
also isn't helpful for folks that have never learned a lower level
language where you're manipulating pointers directly.

However, simply removing the analogy entirely leaves that paragraph in
the documentation feeling incomplete, so it would be valuable to
replace it with a different real world analogy that will make sense to
a broad audience.

Chris's initial suggestion was to use "license number" or "social
security number" (i.e. numbers governments assign to people), but I'm
thinking a better comparison might be to vehicle registration numbers,
since that analogy can be extended to the type and value
characteristics in a fairly straightforward way:

- the object identity is like the registration number or license plate
(unique within the particular system of registering vehicles, but not
unique across systems, and may sometimes be transferred to a new
vehicle after the old one is destroyed)
- the object type is like the make and model (e.g. a 2007 Toyota
Corolla Ascent Sedan)
- the object value is a specific car (e.g. "that white Corolla over
there with 89000 km on the odometer")

On the other hand, we're talking about the language reference here,
not the tutorial, and understanding memory addressing seems like a
reasonable assumed pre-requisite in that context.

Cheers,
Nick.

--
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Need discussion for a PR about memory and objects

2018-11-04 Thread Steven D'Aprano 
On Sun, Nov 04, 2018 at 11:43:50AM +0100, Stephane Wirtel wrote:
> In this PR [https://github.com/python/cpython/pull/3382] "Remove reference 
> to
> address from the docs, as it only causes confusion", opened by Chris
> Angelico, there is a discussion about the right term to use for the
> address of an object in memory.

Why do we need to refer to the address of objects in memory?

Python's execution model is not based on addresses. We can't get the 
address of an object or do anything with it (except via ctypes). At the 
Python layer, objects just exist, they don't logically exist at any 
addressable location.

In fact, they might not exist in a single location -- compound objects 
are split across many locations or can share chunks of memory between 
multiple objects. Objects in Jython and IronPython can move about, those 
in PyPy can disappear from existence and reappear. The concept that 
every object has exactly one fixed location simply isn't correct.

I understand that people wishing to understand the implementation 
details of CPython objects will need to think about C-level concepts 
like memory address, but at the Python level, "address" is not a very 
meaningful or useful concept.


-- 
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Need discussion for a PR about memory and objects

2018-11-04 Thread Stephane Wirtel 

In this PR [https://github.com/python/cpython/pull/3382] "Remove reference to
address from the docs, as it only causes confusion", opened by Chris
Angelico, there is a discussion about the right term to use for the
address of an object in memory.

If you are interested by the topic, you could comment it.

If there is no comments then I think we could close the PR.

Thank you

Stéphane

--
Stéphane Wirtel - https://wirtel.be - @matrixise
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com