Re: Terminology: "reference" versus "pointer"

[Chris Angelico]

On Wed, Sep 16, 2015 at 6:24 PM, Ben Finney  wrote:
> Chris Angelico  writes:
>
>> On Wed, Sep 16, 2015 at 6:14 PM, Gregory Ewing
>>  wrote:
>> > This suggests an alternative model for Python computation. All data
>> > is represented by cats. A variable is a box containing a cat.
>> > Assignment replaces one cat with an entangled copy of another cat,
>> > so that mutating either one affects the other.
>>
>> Quantum computing is the way of the future!
>
> Tachyon computing is the way of the future *and* the past.

What do we want?

Guido's time machine!!

When do we want it?

Before feature freeze... unless we get an exemption... actually,
yaknow, it doesn't much matter.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Chris Angelico]

On Wed, Sep 16, 2015 at 6:14 PM, Gregory Ewing
 wrote:
> Emile van Sebille wrote:
>
>> Shroedingers-cat-was-just-a-cat-in-a-box-too-ly y'rs,
>
>
> The real question is, if you kill Schroedinger's cat, does
> Heisenberg's cat die too? If so, then either they're the
> same cat, or they're two entangled cats.
>
> This suggests an alternative model for Python computation.
> All data is represented by cats. A variable is a box
> containing a cat. Assignment replaces one cat with an
> entangled copy of another cat, so that mutating either
> one affects the other.

Quantum computing is the way of the future!

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Ben Finney]

Chris Angelico  writes:

> On Wed, Sep 16, 2015 at 6:14 PM, Gregory Ewing
>  wrote:
> > This suggests an alternative model for Python computation. All data
> > is represented by cats. A variable is a box containing a cat.
> > Assignment replaces one cat with an entangled copy of another cat,
> > so that mutating either one affects the other.
>
> Quantum computing is the way of the future!

Tachyon computing is the way of the future *and* the past.

-- 
 \  “[Entrenched media corporations will] maintain the status quo, |
  `\   or die trying. Either is better than actually WORKING for a |
_o__)  living.” —ringsnake.livejournal.com, 2007-11-12 |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Gregory Ewing]

Emile van Sebille wrote:


Shroedingers-cat-was-just-a-cat-in-a-box-too-ly y'rs,


The real question is, if you kill Schroedinger's cat, does
Heisenberg's cat die too? If so, then either they're the
same cat, or they're two entangled cats.

This suggests an alternative model for Python computation.
All data is represented by cats. A variable is a box
containing a cat. Assignment replaces one cat with an
entangled copy of another cat, so that mutating either
one affects the other.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Steven D'Aprano]

On Tue, 15 Sep 2015 04:02 am, Random832 wrote:

> The point is that with immutable objects no-one cares if they are three
> objects with the same value, or three references to the same object.

Well, you might care...

a = (1,)*(10**12)
b = (1,)*(10**12)
c = (1,)*(10**12)


Each of those tuples would require a rather lot of memory. The difference
between "a lot" and "three times a lot" could be significant.

But other than memory efficiency, yes, you are correct, there's no real
reason to care about the difference between the two cases.


-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Steven D'Aprano]

On Tue, 15 Sep 2015 03:34 am, Random832 wrote:

> On Mon, Sep 14, 2015, at 13:03, Steven D'Aprano wrote:
>> On Tue, 15 Sep 2015 01:10 am, Random832 wrote:
>> > That's not true in CPython. In fact, the range object in python
>> > contains *four* reference boxes - one more for length.
>> 
>> I really don't see why any of this is relevant to the business being
>> discussed.
> 
> When you're drawing this sort of diagram then what references are held
> by an object are more important than what interfaces it implements.

Hmmm. Well, that's going to be tricky then, at least for some objects. Take
a function object, for example:

   +-+
func > | function object |
   +-+

Nice and simple if you draw it like that. Or:

   +---+
func > | function object   |
   |  -|---> ...
   +-|--|--|---+ 
 |  |  |
 |  |  +---> ...
 V  |
   +-+  |
   | __doc__ |  +--> ...
   +-+


Due to laziness, the diagram is incomplete. But here is a partial list of
references held by each function object. For brevity, I have not included
the leading and trailing underscores:

doc (string, or None);
annotations (dict mapping strings to arbitrary objects);
class (type object);
closure (None, or closure object);
code (code object)
dict (dict mapping strings to arbitrary objects);
module (string)
name (string)

and various more. Some of them, such as __code__, themselves include
references to many other objects. Even relatively small diagrams with only
a few objects could easily expand in complexity.

> 
> Personally I think it's a bit silly to insist on a diagram model where a
> box with an arrow in it pointing at an int object can't be represented
> by a box with an integer in it (where 'int' is any immutable type -
> string, tuple, even range), but people don't like boxes with integers in
> them for some reason.


What's wrong with this?

   +--+
myint ---> |  23  |
   +--+




-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Akira Li]

Random832  writes:
...
> Why can't it describe range(1)? A range object in my model would include
> the start, stop, and step; _not_ the contents of what you would get by
> iterating over it; since that's not part of the physical structure of
> the object, but the consequences of calling methods on it.

start, stop, step attributes (corresponding Python ints) may not exist
("the objects we've talking about have never been created") until you
request them explicitly.

I've mentioned it in another message but to be clear, I consider "parcel
tags" [1] and "box and arrows" [2] (boxes are always empty, they only
point to objects) models to be the same and different from "labelled
box" [3] model (boxes contain objects).

[1]
http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#python-has-names
[2]
http://www.pythontutor.com/visualize.html#code=a0+%3D+a1+%3D+%5B1,+2%5D%0Ab0+%3D+%5B1,+2%5D%0Ab1+%3D+%5B1,+2%5D%0Aa+%3D+%5Ba0,+a1%5D%0Ab+%3D+%5Bb0,+b1%5D%0Adel+a0,+a1,+b0,+b1%0A=display=opt-frontend.js=false=false=false=3=%5B%5D=6
[3]
http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#other-languages-have-variables
 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Random832]

On Mon, Sep 14, 2015, at 10:48, Akira Li wrote:
> start, stop, step attributes (corresponding Python ints) may not exist
> ("the objects we've talking about have never been created") until you
> request them explicitly.

That's not true in CPython. In fact, the range object in python contains
*four* reference boxes - one more for length.

> I've mentioned it in another message but to be clear, I consider "parcel
> tags" [1] and "box and arrows" [2] (boxes are always empty, they only
> point to objects) models to be the same and different from "labelled
> box" [3] model (boxes contain objects).

See, I consider the box and arrow to be the same as the labeled box
model - only the object the boxes contain is an arrow. Except for
special kinds of boxes implemented in some other language, such as the
elements of an array from the array module

The problem with "parcel tags" is that it represents namespaces - or one
particular namespace, I've never seen any version of it that even
clearly talks about locals, let alone different modules - differently
from other kinds of objects.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Steven D'Aprano]

On Mon, 14 Sep 2015 01:23 pm, Akira Li wrote:

> Steven D'Aprano  writes:
> 
>> On Mon, 14 Sep 2015 11:22 am, Akira Li wrote:
>>> Look at the last example:
>>> http://thread.gmane.org/gmane.comp.python.general/782626/focus=782704
>>
>>
>> I'm afraid that page is broken in my browser. Can you not summarise, or
>> link to the specific message? I may be able to use another browser in a
>> day or two, but hopefully the discussion will have moved on by then.
> 
> https://mail.python.org/pipermail/python-list/2015-September/696631.html

Thanks. You mean this example?

  lst = [range(1, 3) for _ in range(3)]
  a = [lst[0], lst[0]]
  b = [lst[1], lst[2]]


I don't see what's difficult about this example. Here's a simple ASCII
drawing:


lst > [ range-object-1 , range-object-2 , range-object-3 ]

a --> [ range-object-1 , range-object-1 ]

b --> [ range-object-2 , range-object-3 ]



Trying to draw an arrow diagram using text is not my idea of a good time,
but I'll give it a go. Requires a monospaced font and an email client that
won't reflow the text:

  +-+--+
  | |  | <--- a
  +--|--+---|--+
 |  |
 |  |
 V  |
  +-+ <-+ ++
  |range| <---|-   |< lst 
  +-+ ++
  +---|-   |
  +-+ |   ++
  +-> |range| <---++--|-   |
  |   +-+  |  ++
  ||
  |   +-+  |
  |   |range| <+
  |   +-+
  |  ^
+-|-+|
|   ||
+---+|
|  -|+
+---+
  ^
  |
  +--- b



Out of the two, I know which one I prefer.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Steven D'Aprano]

On Tue, 15 Sep 2015 01:10 am, Random832 wrote:

> On Mon, Sep 14, 2015, at 10:48, Akira Li wrote:
>> start, stop, step attributes (corresponding Python ints) may not exist
>> ("the objects we've talking about have never been created") until you
>> request them explicitly.
> 
> That's not true in CPython. In fact, the range object in python contains
> *four* reference boxes - one more for length.

I really don't see why any of this is relevant to the business being
discussed.

A range object is an object. It has an interface, e.g. it is sized (has a
length), it has start, stop and step attributes.

But the *implementation* of that interface is (1) irrelevant and (2) subject
to change. Maybe the __len__ method calculates the length on the fly. Maybe
start, stop and step are virtual attributes that extract the appropriate
values from a C-level datastructure inaccessible to pure Python code.

Unless you are the author of the range class, you don't really have any
business worrying about whether range.start is a "reference" to the start
value, or something computed on the fly as needed. It could be either.


-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Akira Li]

Steven D'Aprano  writes:

> On Mon, 14 Sep 2015 01:23 pm, Akira Li wrote:
>
>> Steven D'Aprano  writes:
>> 
>>> On Mon, 14 Sep 2015 11:22 am, Akira Li wrote:
 Look at the last example:
 http://thread.gmane.org/gmane.comp.python.general/782626/focus=782704
>>>
>>>
>>> I'm afraid that page is broken in my browser. Can you not summarise, or
>>> link to the specific message? I may be able to use another browser in a
>>> day or two, but hopefully the discussion will have moved on by then.
>> 
>> https://mail.python.org/pipermail/python-list/2015-September/696631.html
>
> Thanks. You mean this example?
>
>   lst = [range(1, 3) for _ in range(3)]
>   a = [lst[0], lst[0]]
>   b = [lst[1], lst[2]]
>
>
> I don't see what's difficult about this example. Here's a simple ASCII
> drawing:
>
>
> lst > [ range-object-1 , range-object-2 , range-object-3 ]
>
> a --> [ range-object-1 , range-object-1 ]
>
> b --> [ range-object-2 , range-object-3 ]
>

I should have mentioned that lst plays the role of range-object-X in
your diagram i.e., only *a*, *b* names actualy exits (I should add `del
lst` to the example) -- as the original example requires.


> Trying to draw an arrow diagram using text is not my idea of a good time,
> but I'll give it a go. Requires a monospaced font and an email client that
> won't reflow the text:
>
>   +-+--+
>   | |  | <--- a
>   +--|--+---|--+
>  |  |
>  |  |
>  V  |
>   +-+ <-+ ++
>   |range| <---|-   |< lst 
>   +-+ ++
>   +---|-   |
>   +-+ |   ++
>   +-> |range| <---++--|-   |
>   |   +-+  |  ++
>   ||
>   |   +-+  |
>   |   |range| <+
>   |   +-+
>   |  ^
> +-|-+|
> |   ||
> +---+|
> |  -|+
> +---+
>   ^
>   |
>   +--- b
>
>
> Out of the two, I know which one I prefer.

I don't know what it means. If you mean "box and arrows" is superior
somehow then I don't see any difference from the "parcel tags" model
here.

My point is that neither models are detailed enough to describe
meaningfully the behavior of Python code in the general case.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Random832]

On Mon, Sep 14, 2015, at 13:03, Steven D'Aprano wrote:
> On Tue, 15 Sep 2015 01:10 am, Random832 wrote:
> > That's not true in CPython. In fact, the range object in python contains
> > *four* reference boxes - one more for length.
> 
> I really don't see why any of this is relevant to the business being
> discussed.

When you're drawing this sort of diagram then what references are held
by an object are more important than what interfaces it implements.

Personally I think it's a bit silly to insist on a diagram model where a
box with an arrow in it pointing at an int object can't be represented
by a box with an integer in it (where 'int' is any immutable type -
string, tuple, even range), but people don't like boxes with integers in
them for some reason.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Akira Li]

Ned Batchelder  writes:

> On Monday, September 14, 2015 at 3:32:46 PM UTC-4, Akira Li wrote:
>> Ned Batchelder  writes:
>> ...
>> > What do you feel is missing from Steven's diagram?
>> 
>> I don't feel anything missing because I don't expect the model to be
>> more detailed.
>
> Akira, you said, "neither models are detailed enough to describe
> meaningfully the behavior of Python code in the general case."   
>
> I'm wondering what aspect of the code's behavior isn't captured
> in this model?  I know you didn't expect it to be complete, but I'm
> not sure what you think is missing.
>

I don't understand what you are talking about.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Ned Batchelder]

On Monday, September 14, 2015 at 3:32:46 PM UTC-4, Akira Li wrote:
> Ned Batchelder  writes:
> ...
> > What do you feel is missing from Steven's diagram?
> 
> I don't feel anything missing because I don't expect the model to be
> more detailed.

Akira, you said, "neither models are detailed enough to describe
meaningfully the behavior of Python code in the general case."   

I'm wondering what aspect of the code's behavior isn't captured
in this model?  I know you didn't expect it to be complete, but I'm
not sure what you think is missing.

--Ned.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Random832]

On Sun, Sep 13, 2015, at 19:17, Akira Li wrote:
> "do not physically exist" does not make sense. Objects are *never*
> destroyed explicitly in Python (you can only make them
> *unreachable*).

But the objects we've talking about have never been created, because the
__getitem__ method has not been called, because we're talking about the
structure of what _is there_, not the idea of what will happen after you
call some method. The (range, or whatever) object holds no
reference/pointer/whatever (maybe we should just call them arrows?) to
the objects that it will create when you call __getitem__, or even to
the ones that it has created when you've called it, so it doesn't make
sense to put a box in it that will have an arrow pointing to those
objects.

> You can disable garbage collection completely and it is
> still will be Python. Immutable objects can be considered immortal e.g.:
> 
>  (1+1) -- question: does the object that represents int(2) exist before
> the expression is evaluated?
> 
> The correct answer: it does not matter: int(2) can be created on the
> fly, a cached int(2) can be reused by a specific implementation --
> Python doesn't care.
> 
> I don't see why the model that can't describe range(1) in Python 3
> pretends to be complete.

Why can't it describe range(1)? A range object in my model would include
the start, stop, and step; _not_ the contents of what you would get by
iterating over it; since that's not part of the physical structure of
the object, but the consequences of calling methods on it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Chris Angelico]

On Tue, Sep 15, 2015 at 3:51 AM, Emile van Sebille  wrote:
> Actually, boxes with integers in them isn't the appropriate analogy.
> Consider the naming of cats.  My cat is known to me as Paddy.  My next door
> neighbor sometimes feeds her and is known to her as Stripes.  The cat also
> is known as kitty to my youngest daughter.  The cat has no idea what its
> name is, it just is and eats.

Thanks for that. As someone who shares a house with a cat (not my
own), I find this apt and amusing. :)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Ned Batchelder]

On Monday, September 14, 2015 at 1:26:39 PM UTC-4, Akira Li wrote:
> My point is that neither models are detailed enough to describe
> meaningfully the behavior of Python code in the general case.

This is of course true, because a model is never detailed enough to
fully describe the real thing.

I'm curious what aspect of the example here isn't meaningfully
described by the boxes and arrows notation?  It seems to me that
usually the problem is that the diagram is simplified at a certain
level of detail.  For example, the range objects here are presented
as atomic, without revealing that they hold references to other
objects.

What do you feel is missing from Steven's diagram?

--Ned.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Akira Li]

Random832  writes:

> On Mon, Sep 14, 2015, at 10:48, Akira Li wrote:
>> start, stop, step attributes (corresponding Python ints) may not exist
>> ("the objects we've talking about have never been created") until you
>> request them explicitly.
>
> That's not true in CPython. In fact, the range object in python contains
> *four* reference boxes - one more for length.

Even if it true in CPython. Specific implementations are irrelevant for
the discussions. Python -- the language -- does not mandate any
reference boxes (and given how you interpret the term "box" -- boxes are
not used anywhere).

>> I've mentioned it in another message but to be clear, I consider "parcel
>> tags" [1] and "box and arrows" [2] (boxes are always empty, they only
>> point to objects) models to be the same and different from "labelled
>> box" [3] model (boxes contain objects).
>
> See, I consider the box and arrow to be the same as the labeled box
> model - only the object the boxes contain is an arrow. Except for
> special kinds of boxes implemented in some other language, such as the
> elements of an array from the array module

   [box + arrow pointing to] + object == parcel tag + object

I could draw a picture but it won't be pretty.

"labelled box" model that assumes that objects are inside boxes is
clearly wrong -- it fails if you have two names that refer to the same
object in Python (you can't put the same object into different
boxes).

If a box contains nothing then there is no need for the box. If you
think the box contains "something" then find me the corresponding term
in Python language reference. I don't understand what is "arrow" that
the box might contain exactly. For example I can find what "name",
"object" mean in Python.

> The problem with "parcel tags" is that it represents namespaces - or one
> particular namespace, I've never seen any version of it that even
> clearly talks about locals, let alone different modules - differently
> from other kinds of objects.

I don't understand what are you trying to say here. If you have a
specific example when the "parcel tags" [1] model predicts a _wrong_
behavior; please do provide it. If your point is that "parcel tag" does
not describe in full detail all aspect of the behavior of an arbitrary
Python code then I agree with you (though none of the discussed models
can or should do it).

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Akira Li]

Random832  writes:

> On Mon, Sep 14, 2015, at 13:45, Akira Li wrote:
>>[box + arrow pointing to] + object == parcel tag + object
>
> The problem is that if there are multiple namespaces, or if you've also
> got to include references from within other objects such as list, then
> you've got to write all that somehow on the parcel tag, instead of just
> having different places the arrows can start from.
>
> The box and arrow model easily extends to this, and the fact that no-one
> can make up their mind on what to *call* the thing the arrows represent
> doesn't mean they don't exist.

box has arrow, parcel tag has string/thread.
We could attach an arrow instead of a string to the parcel tag.

The box does not contain anything inside (we can attach the arrow
outside the box -- nothing changes).

If the box does not contain anything then we could use a parcel tag
instead.


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Emile van Sebille]

On 9/14/2015 10:34 AM, Random832 wrote:


Personally I think it's a bit silly to insist on a diagram model where a
box with an arrow in it pointing at an int object can't be represented
by a box with an integer in it (where 'int' is any immutable type -
string, tuple, even range), but people don't like boxes with integers in
them for some reason.


Actually, boxes with integers in them isn't the appropriate analogy. 
Consider the naming of cats.  My cat is known to me as Paddy.  My next 
door neighbor sometimes feeds her and is known to her as Stripes.  The 
cat also is known as kitty to my youngest daughter.  The cat has no idea 
what its name is, it just is and eats.  So three labels, one object. 
Putting the object in three boxes isn't right -- how could you know 
(other than checking the id()) that they're the same?


Shroedingers-cat-was-just-a-cat-in-a-box-too-ly y'rs,

Emile



--
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Random832]

On Mon, Sep 14, 2015, at 13:45, Akira Li wrote:
>[box + arrow pointing to] + object == parcel tag + object

The problem is that if there are multiple namespaces, or if you've also
got to include references from within other objects such as list, then
you've got to write all that somehow on the parcel tag, instead of just
having different places the arrows can start from.

The box and arrow model easily extends to this, and the fact that no-one
can make up their mind on what to *call* the thing the arrows represent
doesn't mean they don't exist.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Random832]

On Mon, Sep 14, 2015, at 13:51, Emile van Sebille wrote:
> Actually, boxes with integers in them isn't the appropriate analogy. 
> Consider the naming of cats.  My cat is known to me as Paddy.  My next 
> door neighbor sometimes feeds her and is known to her as Stripes.  The 
> cat also is known as kitty to my youngest daughter.  The cat has no idea 
> what its name is, it just is and eats.  So three labels, one object. 
> Putting the object in three boxes isn't right

The point is that with immutable objects no-one cares if they are three
objects with the same value, or three references to the same object.
Your cat is not an integer.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Akira Li]

Ned Batchelder  writes:
...
> What do you feel is missing from Steven's diagram?

I don't feel anything missing because I don't expect the model to be
more detailed.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Jussi Piitulainen]

Random832 writes:
> Jussi Piitulainen writes:
>> I think the best way is to say that a[0] and a[1] are the same
>> object, while b[0] and b[1] are different objects.
>
> Sure, you can *say* that. But how do you draw it on a diagram with
> sticky notes or parcel tags or whatever?

I prefer to outline my code as code, with comments where needed, without
irrelevant details. Those pointers and tags are usually irrelevant, best
omitted altogether.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Steven D'Aprano]

On Sun, 13 Sep 2015 10:50 pm, Steven D'Aprano wrote:

> On Sun, 13 Sep 2015 04:45 am, ru...@yahoo.com wrote:
... ^


> But as I said to Rurpy, 

Er, that would be you.

Editing fail. Sorry about that.


-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Chris Angelico]

On Mon, Sep 14, 2015 at 1:31 AM, rurpy--- via Python-list
 wrote:
> Ben,
>
> If the troll being taunted here is referring to me, I suggest
> you review my posts in this thread,  You've said in the past
> that you don't read posts from Google Groups (that's fine,
> your choice) so perhaps you do not have a clear idea what I
> have written.

I think Ben's referring to taunting jmf, whom Mark called the "RUE" or
"Resident Unicode Expert". There has been a long-standing antagonism
between those two (which is completely understandable), and one which
often spills over into vitriolic posts (which is less acceptable).

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Steven D'Aprano]

On Sun, 13 Sep 2015 04:45 am, ru...@yahoo.com wrote:

> On 09/12/2015 10:32 AM, Steven D'Aprano wrote:
>> On Sat, 12 Sep 2015 02:42 pm, Random832 wrote:
>>[...]
>> Computer science and IT is *dominated* by a single usage for "pointer" --
>> it's an abstract memory address. The fundamental characteristics of
>> pointers are:
> 
> Just upthread, you claimed something was "universally agreed"

I did? "Universially agreed" doesn't sound like something I would say. Do
you have a link to where I said that?

I think you're confusing me with somebody else. Somebody who is not me.



[...]
>> Python, Java, Ruby, Lua, Javascript etc. have *no such concept* as
>> pointer. There are no values in these languages which correspond to the
>> standard definition of pointer:
> 
> They have not such concept because the developers and documentors choose
> not to describe that language that way. That does not mean one could not
> come up with a perfectly valid description that did include the concept
> of pointers.

I have little problem with you using "pointer" as a metaphor: "Python
variables are like pointers in these ways...". I do have a problem with you
insisting that they are pointers.

You can, if you choose, decide to change the meaning of the word "pointer".
After all, as a general English term, it just means a type of dog. No,
wait, that's the wrong meaning. It means anything which points in some
fashion, like a dog.

But as I said to Rurpy, if you're going to insist on using your own meanings
for words, the onus is on you to ensure that people aren't going to
misunderstand you. Sure, you could insist that `x = math.sin(1)` makes x a
string, and justify that piece of obnoxious linguistic trickery by saying
that x is a string of bits, but I think that we'd be justified in objecting
to that misuse of terminology.

Sure, you can insist that `x = math.sin(1)` makes x a pointer, but that too
is a misuse of terminology.

You can continue to call Python variables "pointers". After all, language is
a construct, and words have no meaning but that we give them, and there is
no law that says you are forbidden from using your own private meaning of
words. And when you do, I shall continue to object vehemently to your
wilful malapropism.


[...]
> It may not be appropriate way to describe Python for everybody but
> it is perfectly reasonable (and even preferable) for people with
> an understanding of "pointers" from some other language. And for
> those people who don't then one could argue they are a clean slate
> and using the word "pointer" won't hurt.

No, it is not reasonable. 

You want to insist that `x = 23` in Python code makes x a pointer. But that
Python snippet is analogous to to the following C and Pascal snippets:

# C
int x = 23;


{Pascal}
var x: integer;
begin 
  x := 23;
end;


Do you insist that they are pointers to? Then everything is a pointer, and
the word has no meaning. 

Regardless of which of the three languages we are talking about, the
assignment `x = 23` does not mean "bind some value to x which, when
dereferenced, gives the value 23". The value bound to x is 23, not some
indirect pointer to 23.

The *implementation* of how names and variables are bound may (or may not)
involve pointers, but that is outside of the language abstraction, whether
we are talking about Python, C or Pascal.

To call x a pointer to 23 breaks the language abstraction and confuses the
(optional) implementation for the language interface:

* CPython's implementation of namespaces may include a hash table, 
  where the table's values are pointers to objects in the heap;

* C's and Pascal's implementation of variables may include a 
  compile-time table of variable names mapped to memory addresses;

All three implementations may include a "thing-which-points" (Python name
bindings may involve C pointers to objects implemented as C structs; Pascal
and C variables may involve a compile-time table that points to the memory
address of the variable being accessed), but NONE of them justifies calling
x a pointer in ANY of those languages. 

If it helps you understand Python's programming model to discuss the
implementation, by all means do so. But be clear that you are talking about
*implementation* and not Python code.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[rurpy--- via Python-list]

On 09/12/2015 08:42 PM, Ben Finney wrote:
> Michael Torrie  writes:
>> On 09/12/2015 08:22 PM, Mark Lawrence wrote:
>>> You appear to have the same level of knowledge of Python internals as 
>>> the RUE has of the Python 3.3+ FSR unicode implementation.  Let's have 
>>> some fun, is Python pass by value or pass by reference?  It has to be 
>>> more interesting debating that than the drivel that's gone before in 
>>> this thread.
>>
>> Oh you are a devious one there! This should get good.
>
> No, it should stop there. Taunting trolls is no more welcome here than
> trolling.

Ben,

If the troll being taunted here is referring to me, I suggest 
you review my posts in this thread,  You've said in the past 
that you don't read posts from Google Groups (that's fine, 
your choice) so perhaps you do not have a clear idea what I 
have written.

One of the most effective ways for a community to discredit 
itself is to make accusations of trolling in response to 
unpopular but legitimate and reasonable opinion.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Akira Li]

Random832  writes:

> Akira Li <4kir4...@gmail.com> writes:
>>Rustom Mody  writes:
>>> viz. I have two variables (or names!) say a and b which look the same
>> a
>>> [[1,2],[1,2]]
>> b
>>> [[1,2],[1,2]]
>>> And yet doing
>> a[0][0] = "Oops!"
>>> gives a data structure one "Oops!"
>>> whereas doing it to b mysteriously gives 2
>>
>> Sorry, I haven't followed the whole thread. Could your provide a
>> complete code example? Mention what you expect to happen and what
>> happens instead in your case.
>
> a0 = a1 = [1, 2]
> b0 = [1, 2]
> b1 = [1, 2]
> a = [a0, a1]
> b = [b0, b1]
> del a0, a1, b0, b1
>
> There's nothing about *him* expecting anything wrong to happen. The
> question is how to draw a diagram that unambiguously shows the resulting
> structure using the "parcel tags" model shown in the diagrams (and
> without having a0/a1/etc as actual names)

I'm not sure what "parcel tags" model is but if you mean these
pictures[1] than it works in this case as well as any other (take *a*,
*b* nametags, put them on the corresponding balloons that represents
list objects).

The only names left are *a* and *b* that refer to the corresponding
lists. There is no ambiguity there to put *a*, *b* nametags.

Lists as any other containers contain references to other objects and
therefore "box and arrows" model provides _more details_ here[2,3]

> If the "parcel tags" model can't show it, then the "parcel tag" model
> clearly is not a correct and complete depiction of how Python actually
> works.
> (If I were drawing a picture rather than ASCII I'd add something to make
> it clear that the pairs shown are list objects Like, it's a circle with
> the word "list" and two pointer-boxes inside it.)

"correct and complete" is impossible in the general case for any model.

Imagine what happens if numpy arrays are used instead of Python lists:

  lst = [numpy.array([1, 2]) for _ in range(3)]
  a = [lst[0], lst[0]]
  b = [lst[1], lst[2]]

Note: there could be no a[0][0], a[0][1], etc corresponding Python
objects until you explicitly reference them in the code. If there are no
Python objects then you can't draw any arrows and therefore "box and
arrows" model is incomplete.

Or consider this collections of all Unicode characters:

  class U:
 def __len__(self):
 return sys.maxunicode + 1
 def __getitem__(self, index):
 if index < 0:
 index += len(self)
 if 0 <= index < len(self):
 return chr(index)
 raise IndexError(index)

  u = U()
  print(u[0x61]) # -> a

In this example, it is even more clear that the corresponding items
might not exist until they are explicitly referenced in a program. *u*
is a sequence as any other in Python (it is easy to make it
*collections.abc.Sequence* compatible).

Or this:

  lst = [range(1, 3) for _ in range(3)]
  a = [lst[0], lst[0]]
  b = [lst[1], lst[2]]

In Python 2, it is the exact replica of the original example. In Python
3, it is the same if you don't need to mutate the ranges. Again, the
leaf objects might not exist until you reference them in the code in
Python 3.

Finally, consider a Python sequence that uses os.urandom()
internally. No model will predict the result (and therefore no model is
complete) in this case.


[1]
http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#python-has-names
[2]
http://www.pythontutor.com/visualize.html#code=a0+%3D+a1+%3D+%5B1,+2%5D%0Ab0+%3D+%5B1,+2%5D%0Ab1+%3D+%5B1,+2%5D%0Aa+%3D+%5Ba0,+a1%5D%0Ab+%3D+%5Bb0,+b1%5D%0Adel+a0,+a1,+b0,+b1%0A=display=opt-frontend.js=false=false=false=3=%5B%5D=6
[3]
http://www.pythontutor.com/visualize.html#code=a0+%3D+a1+%3D+%5B1,+2%5D%0Ab0+%3D+%5B1,+2%5D%0Ab1+%3D+%5B1,+2%5D%0Aa+%3D+%5Ba0,+a1%5D%0Ab+%3D+%5Bb0,+b1%5D%0Adel+a0,+a1,+b0,+b1%0Aa%5B0%5D%5B0%5D+%3D+%22Oops!%22=display=opt-frontend.js=false=false=false=3=%5B%5D=7


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Chris Angelico]

On Mon, Sep 14, 2015 at 4:04 AM, Akira Li <4kir4...@gmail.com> wrote:
>> (If I were drawing a picture rather than ASCII I'd add something to make
>> it clear that the pairs shown are list objects Like, it's a circle with
>> the word "list" and two pointer-boxes inside it.)
>
> "correct and complete" is impossible in the general case for any model.
>
> Imagine what happens if numpy arrays are used instead of Python lists:
>
>   lst = [numpy.array([1, 2]) for _ in range(3)]
>   a = [lst[0], lst[0]]
>   b = [lst[1], lst[2]]
>
> Note: there could be no a[0][0], a[0][1], etc corresponding Python
> objects until you explicitly reference them in the code. If there are no
> Python objects then you can't draw any arrows and therefore "box and
> arrows" model is incomplete.
>
> Or consider this collections of all Unicode characters:
>
>   class U:
>  def __len__(self):
>  return sys.maxunicode + 1
>  def __getitem__(self, index):
>  if index < 0:
>  index += len(self)
>  if 0 <= index < len(self):
>  return chr(index)
>  raise IndexError(index)
>
>   u = U()
>   print(u[0x61]) # -> a
>
> In this example, it is even more clear that the corresponding items
> might not exist until they are explicitly referenced in a program.

What you've shown there is that it's perfectly possible to have an
abstract collection which generates objects as they're needed. In the
same way, you could define an infinite range object, which effectively
has all positive odd numbers in it:

class Odd:
def __getitem__(self, index):
if index >= 0: return index * 2 + 1
raise IndexError(index)

Obviously it can't have objects representing every positive odd
number, because that's an infinite set. If you want to think of this
as containing all of those integers, sure, but now we're getting into
functional programming styles and ways of representing infinity in
finite RAM, and some things will look a bit different.

However, none of this has anything to do with Python's object model.
The expression "index * 2 + 1" results in the creation of new integer
objects as required, rather than simply retrieving them from some
containment list. The boxes-and-arrows stuff is all about pre-existing
objects; if I construct one list from another, I expect all the
references to be the same, but if I construct two Odd() objects, they
don't have to be:

>>> o1 = Odd(); x1 = o1[12345]
>>> o2 = Odd(); x2 = o2[12345]
>>> x1 is x2
False

Even though every Odd() must, by definition, contain the exact same
integers, it doesn't contain the same objects - it doesn't contain any
objects.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Random832]

Akira Li <4kir4...@gmail.com> writes:
> I'm not sure what "parcel tags" model is but if you mean these
> pictures[1] than it works in this case as well as any other (take *a*,
> *b* nametags, put them on the corresponding balloons that represents
> list objects).
>
> The only names left are *a* and *b* that refer to the corresponding
> lists. There is no ambiguity there to put *a*, *b* nametags.

But how do you make an a[0][0]/a[1][0] nametag to put on the "1" object?

> Lists as any other containers contain references to other objects and
> therefore "box and arrows" model provides _more details_ here[2,3]

Right, but why not use the *same* model to represent *namespaces*?

It seems like the "tags" model only exists to make the incorrect claim
that python doesn't have variables (the boxes are variables).

>> If the "parcel tags" model can't show it, then the "parcel tag" model
>> clearly is not a correct and complete depiction of how Python actually
>> works.
>> (If I were drawing a picture rather than ASCII I'd add something to make
>> it clear that the pairs shown are list objects Like, it's a circle with
>> the word "list" and two pointer-boxes inside it.)
>
> "correct and complete" is impossible in the general case for any
> model.

Everything you wrote here has the same issue: The "objects" you are
talking about do not physically exist, but are simply the result of
calling a method on the object. Therefore they do not *belong* on the
diagram, and the diagram not showing them does not mean the diagram is
not complete.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Ben Finney]

Chris Angelico  writes:

> I think Ben's referring to taunting jmf, whom Mark called the "RUE" or
> "Resident Unicode Expert". There has been a long-standing antagonism
> between those two (which is completely understandable), and one which
> often spills over into vitriolic posts (which is less acceptable).

Chris has it right.

What's especially unacceptable is invoking that person for amusement,
irrelevant to the conversation. It's one thing to respond when a person
comes into a thread to troll unbidden; it is quite another to taunt them
unprompted.

-- 
 \ “I call him Governor Bush because that's the only political |
  `\  office he's ever held legally.” —George Carlin, 2008 |
_o__)  |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Akira Li]

Chris Angelico  writes:

> On Mon, Sep 14, 2015 at 9:17 AM, Akira Li <4kir4...@gmail.com> wrote:
>> If you mean this quote from [1]:
>>
>>   Although we commonly refer to "variables" even in Python (because it's
>>   common terminology), we really mean "names" or "identifiers". In
>>   Python, "variables" are nametags for values, not labelled boxes.
>>
>> then *name* is the term that is defined in the Python language
>> reference. The word "variable" we can use in day-to-day programming
>> _unless_ we are discussing issues that are specific to _naming and
>> binding_.  In that case, we should use the _exact_
>> terminology. Otherwise there is nothing wrong with using "variables"
>> casually in Python.
>
> Since you're talking about precise terminology, I think it would be
> better to say "name binding", rather than "naming and binding". When
> you talk of naming something (or someone!), you generally mean that
> it's possible to go from the thing to the (canonical) name. With
> people, for instance, you can walk up to someone and say "Hi! What's
> your name?", but with Python objects, you fundamentally can't.

"Naming and binding" is the title from the Python language reference
https://docs.python.org/3/reference/executionmodel.html#naming-and-binding

Otherwise, I agree with you ("name" is better here).

>>> Everything you wrote here has the same issue: The "objects" you are
>>> talking about do not physically exist, but are simply the result of
>>> calling a method on the object. Therefore they do not *belong* on the
>>> diagram, and the diagram not showing them does not mean the diagram is
>>> not complete.
>>
>> "do not physically exist" does not make sense. Objects are *never*
>> destroyed explicitly in Python (you can only make them
>> *unreachable*). You can disable garbage collection completely and it is
>> still will be Python. Immutable objects can be considered immortal e.g.:
>>
>>  (1+1) -- question: does the object that represents int(2) exist before
>> the expression is evaluated?
>>
>> The correct answer: it does not matter: int(2) can be created on the
>> fly, a cached int(2) can be reused by a specific implementation --
>> Python doesn't care.
>>
>> I don't see why the model that can't describe range(1) in Python 3
>> pretends to be complete.
>
> "Physically" isn't really the right word for it, given that objects in
> Python code aren't physical and therefore don't *ever* "physically
> exist". My bad there.
>
> But the objects completely do not exist. Yes, with integers you can't
> tell... but what about here?
>
> dependencies = collections.defaultdict(list)
> for fn in files:
> for dep in gather_deps(fn):
> dependencies[dep].append(fn)
>
> Until the moment when dependencies[dep] is requested for some new
> value of dep, the list *does not exist*. It is constructed anew.
> Obviously the end result of this is a dict of lists, and since those
> lists aren't accessible from anywhere else, it makes fine sense to
> talk about those lists as being "contained within" the (default)dict;
> but they clearly didn't exist until they were poked at. They're
> Heisenburg's Lists, I guess...

lists are _mutable_ in Python.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[rurpy--- via Python-list]

On 09/13/2015 06:50 AM, Steven D'Aprano wrote:
> On Sun, 13 Sep 2015 04:45 am, ru...@yahoo.com wrote:
>> On 09/12/2015 10:32 AM, Steven D'Aprano wrote:
>>> On Sat, 12 Sep 2015 02:42 pm, Random832 wrote:
>>> [...]
>>> Computer science and IT is *dominated* by a single usage for "pointer" --
>>> it's an abstract memory address. The fundamental characteristics of
>>> pointers are:
>>
>> Just upthread, you claimed something was "universally agreed"
> 
> I did? "Universially agreed" doesn't sound like something I would say. Do
> you have a link to where I said that?
> I think you're confusing me with somebody else. Somebody who is not me.

I should have copy/pasted rather than paraphrasing from memory. You
said "near-universal agreement" ("Re: Python handles globals badly",
2015-09-10). The difference does not change my response at all.

> [...]
> I have little problem with you using "pointer" as a metaphor: "Python
> variables are like pointers in these ways...". I do have a problem with you
> insisting that they are pointers.

First, I am very cautious about about using absolute and dogmatic
words like *are* [pointers] (although I probably have occasionally
for brevity or in response to someones else's dogmatism.)

If you go back over what I've written, I think you'll see that my
main point is that describing what is in python "variables" and objects
as pointers can be useful in some circumstances as an alternative
to the current official description (with people who have had some
experience with pointers in other languages, for example).

The "standard definition" you keep referring to (and basing your
arguments on was):

  An address, from the point of view of a programming language.[...]

Wikipedia also seems to define pointer in terms of memory address.
As I said, I think when describing the behavior of a language in abstract
terms it is perfectly valid to take "address" equally abstractly (eg a
token that lets you retrieve the same data every time you use it) but
unfortunately for me Wikipedia defines "address" as the conventional
linear numbers used in real-world computers. And I am not going to
waste my time trying to convince anyone that Wikipedia is wrong or
the context in inappropriate.

Wikipedia also makes a distinction between "pointer" as something
that refers to some data by "memory address" and "reference" which
refers to some data by any means (including but not limited to a
memory address, eg offset from current address or url). That was
not distinction I knew of; I considered both terms as being more or
less synonymous (in the general sense, obviously they are different
in specific domains like C++).

So I will retract any claim I made about "pointer" being a technically
correct term (because Python-the-language imposes no restrictions on
on how references are implemented.)

Nevertheless I'll continue to maintain that it is useful to explain
how python works in terms of pointers in that:

1) The distinction between abstract pointers(*) and references
is non-existant or irrelevant in Python for any existing
implementation.

2) You can accurately specify python-the-language in term of
abstract pointers (ie, "as if") regardless of how it is currently
specified.

3) People who've used pointers in other languages are more easily
able to grasp Python semantics when presented in term of pointers,
a concept they already understand.

(*) by "abstract pointers" I mean pointers in the sense given in
your definition, not C datatype pointers. If you insist on "references"
that's ok too, the description can be accompanied with a wink and a
whispered, "hey, references are really like pointers".)

Those are my opinions, if you have any clear counter examples I
would certainly like to know of them but I've not seen or read
anything yet that indicates they are wrong.

Below I snipped out all your responses that were essentially "that's
not the standard definition of pointers", having addressed those above.

> [...]

>> It may not be appropriate way to describe Python for everybody but
>> it is perfectly reasonable (and even preferable) for people with
>> an understanding of "pointers" from some other language. And for
>> those people who don't then one could argue they are a clean slate
>> and using the word "pointer" won't hurt.
> 
> No, it is not reasonable. 
> 
> You want to insist that `x = 23` in Python code makes x a pointer. But that
> Python snippet is analogous to to the following C and Pascal snippets:
> 
> # C
> int x = 23;
> 
> [...pascal example snipped...]
> 
> Do you insist that they are pointers to? 
>
> Then everything is a pointer, and the word has no meaning.
>
> Regardless of which of the three languages we are talking about, the
> assignment `x = 23` does not mean "bind some value to x which, when
> dereferenced, gives the value 23".
>
> The value bound to x is 23, not some
> indirect pointer to 23.

Your problem is that the C snippet is not, as you claim, analogous
to the Python 

Re: Terminology: "reference" versus "pointer"

[Akira Li]

Random832  writes:

> Akira Li <4kir4...@gmail.com> writes:
>> I'm not sure what "parcel tags" model is but if you mean these
>> pictures[1] than it works in this case as well as any other (take *a*,
>> *b* nametags, put them on the corresponding balloons that represents
>> list objects).
>>
>> The only names left are *a* and *b* that refer to the corresponding
>> lists. There is no ambiguity there to put *a*, *b* nametags.
>
> But how do you make an a[0][0]/a[1][0] nametag to put on the "1" object?

a[0][0]/a[1][0] are not names. Though if we want to talk about the
corresponding objects then a[0][0]/a[1][0] could be used instead of
names (as a way to identify them). 

>> Lists as any other containers contain references to other objects and
>> therefore "box and arrows" model provides _more details_ here[2,3]
>
> Right, but why not use the *same* model to represent *namespaces*?

If it works for your case; use it. The links [2,3] show that It does
work in this case (if it is correct to call what they show "box and
arrows" model).

> It seems like the "tags" model only exists to make the incorrect claim
> that python doesn't have variables (the boxes are variables).

If you mean this quote from [1]:

  Although we commonly refer to "variables" even in Python (because it's
  common terminology), we really mean "names" or "identifiers". In
  Python, "variables" are nametags for values, not labelled boxes.

then *name* is the term that is defined in the Python language
reference. The word "variable" we can use in day-to-day programming
_unless_ we are discussing issues that are specific to _naming and
binding_.  In that case, we should use the _exact_
terminology. Otherwise there is nothing wrong with using "variables"
casually in Python.

Notice: that [2,3] model is different from "labelled boxes" model. There
are arrows from *a*/*b* _to_ list objects i.e., *a*/*b* are not boxes
that _contain_ list objects within --
_otherwise you have to put the *same* list into two *different* boxes_ --
let's not investigate quantum paradoxes here. The only difference from
"parcel tags" model is that list items do not have explicit names.

>>> If the "parcel tags" model can't show it, then the "parcel tag" model
>>> clearly is not a correct and complete depiction of how Python actually
>>> works.
>>> (If I were drawing a picture rather than ASCII I'd add something to make
>>> it clear that the pairs shown are list objects Like, it's a circle with
>>> the word "list" and two pointer-boxes inside it.)
>>
>> "correct and complete" is impossible in the general case for any
>> model.
>
> Everything you wrote here has the same issue: The "objects" you are
> talking about do not physically exist, but are simply the result of
> calling a method on the object. Therefore they do not *belong* on the
> diagram, and the diagram not showing them does not mean the diagram is
> not complete.

"do not physically exist" does not make sense. Objects are *never*
destroyed explicitly in Python (you can only make them
*unreachable*). You can disable garbage collection completely and it is
still will be Python. Immutable objects can be considered immortal e.g.:

 (1+1) -- question: does the object that represents int(2) exist before
the expression is evaluated?

The correct answer: it does not matter: int(2) can be created on the
fly, a cached int(2) can be reused by a specific implementation --
Python doesn't care.

I don't see why the model that can't describe range(1) in Python 3
pretends to be complete.

[1]
http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#python-has-names
[2]
http://www.pythontutor.com/visualize.html#code=a0+%3D+a1+%3D+%5B1,+2%5D%0Ab0+%3D+%5B1,+2%5D%0Ab1+%3D+%5B1,+2%5D%0Aa+%3D+%5Ba0,+a1%5D%0Ab+%3D+%5Bb0,+b1%5D%0Adel+a0,+a1,+b0,+b1%0A=display=opt-frontend.js=false=false=false=3=%5B%5D=6
[3]
http://www.pythontutor.com/visualize.html#code=a0+%3D+a1+%3D+%5B1,+2%5D%0Ab0+%3D+%5B1,+2%5D%0Ab1+%3D+%5B1,+2%5D%0Aa+%3D+%5Ba0,+a1%5D%0Ab+%3D+%5Bb0,+b1%5D%0Adel+a0,+a1,+b0,+b1%0Aa%5B0%5D%5B0%5D+%3D+%22Oops!%22=display=opt-frontend.js=false=false=false=3=%5B%5D=7



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Steven D'Aprano]

On Mon, 14 Sep 2015 09:17 am, Akira Li wrote:

> I don't see why the model that can't describe range(1) in Python 3
> pretends to be complete.


Please explain.

range(1) returns a range instance. What is hard about that?



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Akira Li]

Chris Angelico  writes:

> On Mon, Sep 14, 2015 at 11:22 AM, Akira Li <4kir4...@gmail.com> wrote:
>> Steven D'Aprano  writes:
>>
>>> On Mon, 14 Sep 2015 09:17 am, Akira Li wrote:
>>>
 I don't see why the model that can't describe range(1) in Python 3
 pretends to be complete.
>>>
>>>
>>> Please explain.
>>>
>>> range(1) returns a range instance. What is hard about that?
>>
>> Look at the last example:
>> http://thread.gmane.org/gmane.comp.python.general/782626/focus=782704
>
> Still not sure what the problem is. As per Python's object model, the
> lists contain references to range objects. a contains two references
> to the same range object, b contains references to each of two
> distinct range objects. What of it?

For me, there is no problem. "parcel tags" [1], "box and arrows"[2] are
all the same (note: "labelled box"[3] that may contain an object is a
different model).

The talk about being "complete" is caused by the following quote from
Random832 message [4]:

  If the "parcel tags" model can't show it, then the "parcel tag" model
  clearly is not a correct and complete depiction of how Python actually
  works.

The purpose of the examples in [5] is to demonstate that neither models
are "complete" i.e., there is (obviously) behavior of a Python program
that they can't describe.

[1]
http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#python-has-names
[2]
http://www.pythontutor.com/visualize.html#code=a0+%3D+a1+%3D+%5B1,+2%5D%0Ab0+%3D+%5B1,+2%5D%0Ab1+%3D+%5B1,+2%5D%0Aa+%3D+%5Ba0,+a1%5D%0Ab+%3D+%5Bb0,+b1%5D%0Adel+a0,+a1,+b0,+b1%0A=display=opt-frontend.js=false=false=false=3=%5B%5D=6
[3]
http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#other-languages-have-variables
[4]
http://thread.gmane.org/gmane.comp.python.general/782626/focus=782645
[5]
http://thread.gmane.org/gmane.comp.python.general/782626/focus=782704

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Steven D'Aprano]

On Mon, 14 Sep 2015 11:22 am, Akira Li wrote:

> Steven D'Aprano  writes:
> 
>> On Mon, 14 Sep 2015 09:17 am, Akira Li wrote:
>>
>>> I don't see why the model that can't describe range(1) in Python 3
>>> pretends to be complete.
>>
>>
>> Please explain.
>>
>> range(1) returns a range instance. What is hard about that?
> 
> Look at the last example:
> http://thread.gmane.org/gmane.comp.python.general/782626/focus=782704


I'm afraid that page is broken in my browser. Can you not summarise, or link
to the specific message? I may be able to use another browser in a day or
two, but hopefully the discussion will have moved on by then.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Chris Angelico]

On Mon, Sep 14, 2015 at 9:17 AM, Akira Li <4kir4...@gmail.com> wrote:
> If you mean this quote from [1]:
>
>   Although we commonly refer to "variables" even in Python (because it's
>   common terminology), we really mean "names" or "identifiers". In
>   Python, "variables" are nametags for values, not labelled boxes.
>
> then *name* is the term that is defined in the Python language
> reference. The word "variable" we can use in day-to-day programming
> _unless_ we are discussing issues that are specific to _naming and
> binding_.  In that case, we should use the _exact_
> terminology. Otherwise there is nothing wrong with using "variables"
> casually in Python.

Since you're talking about precise terminology, I think it would be
better to say "name binding", rather than "naming and binding". When
you talk of naming something (or someone!), you generally mean that
it's possible to go from the thing to the (canonical) name. With
people, for instance, you can walk up to someone and say "Hi! What's
your name?", but with Python objects, you fundamentally can't.

>> Everything you wrote here has the same issue: The "objects" you are
>> talking about do not physically exist, but are simply the result of
>> calling a method on the object. Therefore they do not *belong* on the
>> diagram, and the diagram not showing them does not mean the diagram is
>> not complete.
>
> "do not physically exist" does not make sense. Objects are *never*
> destroyed explicitly in Python (you can only make them
> *unreachable*). You can disable garbage collection completely and it is
> still will be Python. Immutable objects can be considered immortal e.g.:
>
>  (1+1) -- question: does the object that represents int(2) exist before
> the expression is evaluated?
>
> The correct answer: it does not matter: int(2) can be created on the
> fly, a cached int(2) can be reused by a specific implementation --
> Python doesn't care.
>
> I don't see why the model that can't describe range(1) in Python 3
> pretends to be complete.

"Physically" isn't really the right word for it, given that objects in
Python code aren't physical and therefore don't *ever* "physically
exist". My bad there.

But the objects completely do not exist. Yes, with integers you can't
tell... but what about here?

dependencies = collections.defaultdict(list)
for fn in files:
for dep in gather_deps(fn):
dependencies[dep].append(fn)

Until the moment when dependencies[dep] is requested for some new
value of dep, the list *does not exist*. It is constructed anew.
Obviously the end result of this is a dict of lists, and since those
lists aren't accessible from anywhere else, it makes fine sense to
talk about those lists as being "contained within" the (default)dict;
but they clearly didn't exist until they were poked at. They're
Heisenburg's Lists, I guess...

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Chris Angelico]

On Mon, Sep 14, 2015 at 10:30 AM, Akira Li <4kir4...@gmail.com> wrote:
> "Naming and binding" is the title from the Python language reference
> https://docs.python.org/3/reference/executionmodel.html#naming-and-binding
>
> Otherwise, I agree with you ("name" is better here).

Ah, gotcha. That's talking in much broader scope, so "naming" makes a
bit more sense there. In any case, I can't think of a better term for
it in the full context.

>> Until the moment when dependencies[dep] is requested for some new
>> value of dep, the list *does not exist*. It is constructed anew.
>> Obviously the end result of this is a dict of lists, and since those
>> lists aren't accessible from anywhere else, it makes fine sense to
>> talk about those lists as being "contained within" the (default)dict;
>> but they clearly didn't exist until they were poked at. They're
>> Heisenburg's Lists, I guess...
>
> lists are _mutable_ in Python.

So? Objects are objects. Some of them have no means of changing their
values, while others do. But the Python object model is absolutely the
same for all of them; it's not "pass by value for immutables, pass by
reference for mutables" as some have tried to claim. Immutable objects
have values and identities; the only difference is that the compiler
is allowed to constant-fold, using the same string "hello" in each of
the three places where such a string comes up, or sharing the tuple
(1,2,None) across usages.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Akira Li]

Steven D'Aprano  writes:

> On Mon, 14 Sep 2015 09:17 am, Akira Li wrote:
>
>> I don't see why the model that can't describe range(1) in Python 3
>> pretends to be complete.
>
>
> Please explain.
>
> range(1) returns a range instance. What is hard about that?

Look at the last example:
http://thread.gmane.org/gmane.comp.python.general/782626/focus=782704

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[rurpy--- via Python-list]

On Sunday, September 13, 2015 at 2:49:13 PM UTC-6, Ben Finney wrote:
> Chris Angelico  writes:
> 
> > I think Ben's referring to taunting jmf, whom Mark called the "RUE" or
> > "Resident Unicode Expert". There has been a long-standing antagonism
> > between those two (which is completely understandable), and one which
> > often spills over into vitriolic posts (which is less acceptable).
> 
> Chris has it right.
> 
> What's especially unacceptable is invoking that person for amusement,
> irrelevant to the conversation. It's one thing to respond when a person
> comes into a thread to troll unbidden; it is quite another to taunt them
> unprompted.

Thank you for making that clear.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Chris Angelico]

On Mon, Sep 14, 2015 at 11:22 AM, Akira Li <4kir4...@gmail.com> wrote:
> Steven D'Aprano  writes:
>
>> On Mon, 14 Sep 2015 09:17 am, Akira Li wrote:
>>
>>> I don't see why the model that can't describe range(1) in Python 3
>>> pretends to be complete.
>>
>>
>> Please explain.
>>
>> range(1) returns a range instance. What is hard about that?
>
> Look at the last example:
> http://thread.gmane.org/gmane.comp.python.general/782626/focus=782704

Still not sure what the problem is. As per Python's object model, the
lists contain references to range objects. a contains two references
to the same range object, b contains references to each of two
distinct range objects. What of it?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Akira Li]

Steven D'Aprano  writes:

> On Mon, 14 Sep 2015 11:22 am, Akira Li wrote:
>> Look at the last example:
>> http://thread.gmane.org/gmane.comp.python.general/782626/focus=782704
>
>
> I'm afraid that page is broken in my browser. Can you not summarise, or link
> to the specific message? I may be able to use another browser in a day or
> two, but hopefully the discussion will have moved on by then.

https://mail.python.org/pipermail/python-list/2015-September/696631.html

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Mark Lawrence]

On 14/09/2015 02:34, rurpy--- via Python-list wrote:

Goodbye, *plonk*

--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Rustom Mody]

On Saturday, September 12, 2015 at 10:02:40 PM UTC+5:30, Steven D'Aprano wrote:
> On Sat, 12 Sep 2015 02:42 pm, Random832 wrote:
> 
> > Anyway, maybe we do need a term to distinguish Python/C#/Java pointers
> > from C/C++ pointers - maybe call it a "non-arithmetic" pointer, since
> > the key thing about it is you can't do pointer arithmetic on them to get
> > the object "next to" the one it points at.
> 
> How about *just don't call them pointers*? You know, since they aren't
> pointers in the computer science sense.
> 
> The Free On-line Dictionary of Computing defines "pointer":
> 
>1.  An address, from the point of view of a
>programming language.  A pointer may be typed, with its type
>indicating the type of data to which it points.



> Insisting that Python has pointers is like insisting that you use a text
> editor by flipping bits. "What happens if I press Ctrl-X?" "Well, these
> bits on the screen flip from black to white, these bits flip from white to
> black, and these stay the same."
> 

This is from the docs
https://docs.python.org/3/library/functions.html#id

id(object)

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.

CPython implementation detail: This is the address of the object in memory.


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Steven D'Aprano]

On Sat, 12 Sep 2015 10:46 pm, Rustom Mody wrote:

> On Saturday, September 12, 2015 at 11:57:01 AM UTC+5:30, Ben Finney wrote:

>> You've clearly committed to some ontology that just doesn't match the
>> Python data model.
> 
> How about lay-English ontology in which "point to" and "refer to" are
> fairly synonymous?

"Pointer" in English is also a synonym for 

- a type of dog;
- an instrument which pierces (as used by engravers, lace workers, etc); 
- an item of private information; 
- a hint or tip; 
- a caution or warning; 
- a recommendation; 
- the index finger; 
- a cricketer fielding at a specific position; 
- the hour/minute/second hand on a timepiece; 
- a compass needle; 
- two specific stars in the constellation of the Great Bear (Ursa Major);
-  diagonal braces fastened across the hold of a ship;
- the small icon whose movement across the screen follows that of the 
  mouse, trackball or other pointing device; 
- a signpost or milepost; 

and more. I don't think that arguing on the basis of lay-English or plain
English terms is going to be terribly useful.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Rustom Mody]

On Saturday, September 12, 2015 at 9:47:33 PM UTC+5:30, rurpy wrote:
> Frankly, I feel a little insulted by people who presume that having 
> learned what a pointer is in C, that my brain is so rigid that I must 
> necessarily think that pointer means exactly what pointer means in C
> forever after.

Its more amusing than insulting
Just open CPython sources and there's a pointer on every other line

Best I can see, the people frothing at the mouth that python has no pointers
are basically saying that "non-first-class" == "non-existent"

By that same logic C has neither types nor functions

Speaking as a teacher, sometimes one needs to be clean and dishonest
Sometimes one needs to be honest and mop up after leaky abstractions
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Steven D'Aprano]

On Sun, 13 Sep 2015 02:17 am, ru...@yahoo.com wrote:

> Having programmed in C in the past, 

Well, there's your problem. Like BASIC before it, anyone who has learned C
is mentally crippled for life as a programmer *wink*


> the model of Python I eventually 
> developed is very much (I think, haven't read the whole thread) like
> Random832's.  I think of boxes (objects) with slots containing "pointers"
> that "point" to other boxes.  Even today when dealing with complex
> Python data structures, I draw boxes and arrows to help me understand
> them and think of the arrows as "pointers".

If you're going to abuse terminology, why don't you call the boxes "floats"
since they "float around in memory", or some other story? After all, the
JVM and .NET runtimes can and will move the boxes around as needed, which
is sort of floating around. Then you can say that all Python objects are
floats.

Of course, what *you* mean by float is not what everyone else means by
floats. But you've already made it clear that you're happy to use your own
special meaning of "pointer" that disagrees with the computer science
standard meaning, so what's the difference?


> Frankly, I feel a little insulted by people who presume that having
> learned what a pointer is in C, that my brain is so rigid that I must
> necessarily think that pointer means exactly what pointer means in C
> forever after.

You C programmers, you always think it's about C *wink*

C is not the only, or even the first, language to have standardised on a
meaning for pointer in computer science. Pascal had pointers long before C,
and I'm sure Pascal wasn't the first either.

"Pointer" is a standard primitive data type across dozens of languages: it's
an abstract data type holding the memory address of a variable (either a
named, statically allocated variable, or more often, an anonymous,
dynamically allocated variable). As such, it requires that variables have a
fixed address. If the variable can move, the pointer will no longer point
to the variable.

If you want to use "pointer" to refer to something else, the onus is on you
to make it clear that you're using it in a non-standard way.

Some day, most programmers will be using nothing by dynamic languages which
lack pointers-the-data-type, and the term will lose its baggage and can be
safely used as a generic English term for "a thing which points". The tiny
minority of systems programmers writing device drivers and kernel code in
Rust (C having been long-since delegated to the wastebin of history -- well
that's my fantasy and I'm sticking to it) will learn that, outside of their
own niche, "pointer" does not have the technical meaning that they are used
to, and everyone else will be as blissfully unaware of said technical
meaning as the average programmer today is of continuations and futures.

But this is not that day.


> FYI (the general you), I am capable of extracting the 
> general principle and applying it to Python.  Not just capable, but
> using the concept from C made understanding Python faster than pretending
> that somehow Python has some magical and unique way of structuring data
> that's brand new.

It's not magical or unique. It is shared by many other languages, such as
Ruby, Lua, Java, Javascript.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Rustom Mody]

On Saturday, September 12, 2015 at 11:26:18 PM UTC+5:30, Akira Li wrote:
> Rustom Mody  writes:
> 
> > On Saturday, September 12, 2015 at 8:11:49 PM UTC+5:30, Laura Creighton 
> > wrote:
> >> In a message of Sat, 12 Sep 2015 05:46:35 -0700, Rustom Mody writes:
> >> >How about lay-English ontology in which "point to" and "refer to" are 
> >> >fairly
> >> >synonymous?
> >> 
> >> This I have found is important in teaching, which is why I favour 'bind'
> >> and 'binding' -- rather than pointer, pointer, refer to, referring.
> >
> > Well we can play humpty dumpty and make any word mean whatever we like.
> > However if you are a teacher you will recognize a need for pictures.
> > And (as far as I can tell) "Random832" finds a need for the box-n-arrow
> > diagrams of classic data-structure books
> 
> Speaking of pictures and names in Python
> http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#other-languages-have-variables

Yeah cute
[I think I will even use these in my classes]
However they dont address the issue that I think random832 is referring to.
viz. I have two variables (or names!) say a and b which look the same
>>> a
[[1,2],[1,2]]
>>> b
[[1,2],[1,2]]
And yet doing
>>> a[0][0] = "Oops!"
gives a data structure one "Oops!"
whereas doing it to b mysteriously gives 2

Best I can see you can only explain this 
seemingly-similar-but-structurally-different
with box-n-arrow diagrams.
Or some moral equivalent.

And some people see no advantage to playing semantics and proclaiming
"The arrows in C look similar to the arrows in python but they are not the same"
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Random832]

Akira Li <4kir4...@gmail.com> writes:
>Rustom Mody  writes:
>> viz. I have two variables (or names!) say a and b which look the same
> a
>> [[1,2],[1,2]]
> b
>> [[1,2],[1,2]]
>> And yet doing
> a[0][0] = "Oops!"
>> gives a data structure one "Oops!"
>> whereas doing it to b mysteriously gives 2
>
> Sorry, I haven't followed the whole thread. Could your provide a
> complete code example? Mention what you expect to happen and what
> happens instead in your case.

a0 = a1 = [1, 2]
b0 = [1, 2]
b1 = [1, 2]
a = [a0, a1]
b = [b0, b1]
del a0, a1, b0, b1

There's nothing about *him* expecting anything wrong to happen. The
question is how to draw a diagram that unambiguously shows the resulting
structure using the "parcel tags" model shown in the diagrams (and
without having a0/a1/etc as actual names)

It's easy to draw such a diagram for the "boxes and arrows" model:

(@ shows the box named by a[0][0]. Or a[1][0].)

a[*]-->[*]v   
   [*]-->[@]->(1)
 [*]-.^^
 `++--.
b[*]-->[*]-->[*]--'|  |
   [*]-. [*]---+-.|
   v   | ||
  [*]--' vv
  [*]--->(2)

If the "parcel tags" model can't show it, then the "parcel tag" model
clearly is not a correct and complete depiction of how Python actually
works.

(If I were drawing a picture rather than ASCII I'd add something to make
it clear that the pairs shown are list objects Like, it's a circle with
the word "list" and two pointer-boxes inside it.)

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Mark Lawrence]

On 12/09/2015 23:34, rurpy--- via Python-list wrote:

On 09/12/2015 04:14 PM, Emile van Sebille wrote:

On 9/12/2015 12:58 PM, rurpy--- via Python-list wrote:


The question is whether what "pointer" means in languages that use the
word is*so*  different than its meaning in the Python sense


I can't find a single reference to pointer in the python docs outside
of ctypes.  What is its python sense?


I should have said "proposed sense" (except I don't really mean
proposed as in "let's change all the docs" but as "let's stop the
hissy-fits when someone uses the term"), i.e. the way I, I think
random832, and others use it re python. Sorry, I see in retrospect
my phrasing could be confusing.



The "hissy-fits" are caused because Python the language does not have 
pointers, so by definition there is no need to mention them in any way, 
shape or form in any Python thread.  What is so difficult to understand 
about that?  I would say it's not rocket science, but the insurers that 
paid out over Ariane 5 maybe wouldn't be too happy with that.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[rurpy--- via Python-list]

On 09/12/2015 10:32 AM, Steven D'Aprano wrote:
> On Sat, 12 Sep 2015 02:42 pm, Random832 wrote:
>[...]
> Computer science and IT is *dominated* by a single usage for "pointer" --
> it's an abstract memory address. The fundamental characteristics of
> pointers are:

Just upthread, you claimed something was "universally agreed"
that was not so at all; so please forgive me for not taking your
*dominated*/single assertion on simply your claim that it is so.
 
> - they are first-class values; you can assign a pointer to a variable;

Not true for Python "pointers"

> - you can dereference a pointer: get the value pointed to;

True for Python "pointers"

> - (in some languages) you can get a pointer to a specific variable (possibly
> an unnamed, dynamic variable allocated in the heap rather than a named,
> statically allocated variable).

True for Python "pointers".

> The last two imply that the language must be one where values have fixed
> addresses, not just as a matter of implementation, but as a matter of
> language semantics. If they are free to move, they cannot have a fixed
> address.

The *address* must be fixed, that is, when you dereference the address
you must always get the same thing back. But that implies nothing about
how or where the thing is stored, or whether it can move or not.

Indeed C and other languages with what even you call pointers get the same
thing back even though the thing actually *has* moved in physical memory,
because the address is denoted as a virtual memory address. I take the
generalized meaning of "address" to be simply a token that allows you
to get back the same thing each time you use it.

> Python, Java, Ruby, Lua, Javascript etc. have *no such concept* as pointer.
> There are no values in these languages which correspond to the standard
> definition of pointer:

They have not such concept because the developers and documentors choose
not to describe that language that way. That does not mean one could not
come up with a perfectly valid description that did include the concept
of pointers.

> - you cannot get a pointer to an object or a variable (a name);
> 
> - since there are no pointers, you cannot dereference them;
> 
> - or assign them to a variable.
> 
> 
> Since pointers can be considered an indirect reference to a value, what sort
> of indirect references does Python have? The simplest thing in Python that
> is somewhat analogous to a pointer is a *name*, since names allow you to
> indirectly refer to some value:
> 
> x = 23
> print(x)  # prints the value referred to by x, not "x" itself.
> ptr = "x"  # equivalent to "the address of x"
> y = globals()[ptr]  # equivalent to dereferencing

Here is another kind of indirect reference

a[0] = 23

The "pointer" in the first item of the list "a" does not have a
name. But we can still dereference it.  The dereferencing happens
automatically when "a[0]" is executed.

> Note that names are not first-class values in Python: there is no Name type,
> and you cannot bind a name to a variable, you have to use a string.
> 
> It's not a very close analogy, but it's the closest Python has.

I think it is a close analogy. Things refer to other things and can
be used to access those other things act like pointers. You are correct
that they are not first class items: one cannot do with them everything
one can do with other items, all one can actually do with them is create
them and dereference them. That of course is a good thing. But that
they are not first class objects does not mean that one can't or shouldn't
use the term "pointer" to describe them. That is, I don't see first-
classness as being a requirement for pointerness. The defining
characteristic of a pointer is that it, well, points to something.

It may not be appropriate way to describe Python for everybody but
it is perfectly reasonable (and even preferable) for people with
an understanding of "pointers" from some other language. And for
those people who don't then one could argue they are a clean slate
and using the word "pointer" won't hurt.

(JFTR, I am not against describing python in terms of "reference",
"binding" etc, I just object to the vehement frothing at the mouth
and insistence of one Single Truth that occurs here whenever anyone
attempts to present some alternative. As I said in another post one
size does not fit all.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Chris Angelico]

On Sun, Sep 13, 2015 at 9:39 AM, Rustom Mody  wrote:
> To which we have Chris saying CPython ≠ Python
> Which reminds me of another definition
> Fig-Leaf: A device for converting poor porn into high art
>
> Even in languages like C with an ISO standard adhering to the standard is
> academic (gcc's switch is --pedantic) and it is in practice major
> implementations like gcc and MSC that define and push the standard.
>
> In python, CPython is the standard and other implementations can lay claim to
> being 'python' to the extent that they adhere to the standard.
>
> Or have I missed some ISO-ization?

ISO hasn't standardized Python, but the Python developers do
distinguish between the language and the various implementations. Yes,
CPython does push forward ahead of the others, and thus sometimes
another Python will replicate CPython behaviour rather than seeking an
official language pronouncement; but other times, the PyPy or Jython
or Brython folks come to python-dev with a question. As a general
rule, most PEPs are about the language, not the implementation, so you
can eyeball those to see what you'd need to implement to write a
Python from scratch.

CPython does not intrinsically define the standard. Some languages are
done this way (Pike, for instance), but Python is not.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Akira Li]

Rustom Mody  writes:

> On Saturday, September 12, 2015 at 8:11:49 PM UTC+5:30, Laura Creighton wrote:
>> In a message of Sat, 12 Sep 2015 05:46:35 -0700, Rustom Mody writes:
>> >How about lay-English ontology in which "point to" and "refer to" are fairly
>> >synonymous?
>> 
>> This I have found is important in teaching, which is why I favour 'bind'
>> and 'binding' -- rather than pointer, pointer, refer to, referring.
>
> Well we can play humpty dumpty and make any word mean whatever we like.
> However if you are a teacher you will recognize a need for pictures.
> And (as far as I can tell) "Random832" finds a need for the box-n-arrow
> diagrams of classic data-structure books

Speaking of pictures and names in Python
http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#other-languages-have-variables


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Rustom Mody]

On Sunday, September 13, 2015 at 4:05:21 AM UTC+5:30, ru...@yahoo.com wrote:
> On 09/12/2015 04:14 PM, Emile van Sebille wrote:
> > On 9/12/2015 12:58 PM, rurpy--- via Python-list wrote:
> > 
> >> The question is whether what "pointer" means in languages that use the
> >> word is*so*  different than its meaning in the Python sense
> > 
> > I can't find a single reference to pointer in the python docs outside
> > of ctypes.  What is its python sense?
> 
> I should have said "proposed sense" (except I don't really mean
> proposed as in "let's change all the docs" but as "let's stop the
> hissy-fits when someone uses the term"), i.e. the way I, I think
> random832, and others use it re python. Sorry, I see in retrospect
> my phrasing could be confusing.

Here is my post a little way up:


---
On Saturday, September 12, 2015 at 10:02:40 PM UTC+5:30, Steven D'Aprano wrote:
> On Sat, 12 Sep 2015 02:42 pm, Random832 wrote:
>
> > Anyway, maybe we do need a term to distinguish Python/C#/Java pointers
> > from C/C++ pointers - maybe call it a "non-arithmetic" pointer, since
> > the key thing about it is you can't do pointer arithmetic on them to get
> > the object "next to" the one it points at.
>
> How about *just don't call them pointers*? You know, since they aren't
> pointers in the computer science sense.
>
> The Free On-line Dictionary of Computing defines "pointer":
>
>1.  An address, from the point of view of a
>programming language.  A pointer may be typed, with its type
>indicating the type of data to which it points.



> Insisting that Python has pointers is like insisting that you use a text
> editor by flipping bits. "What happens if I press Ctrl-X?" "Well, these
> bits on the screen flip from black to white, these bits flip from white to
> black, and these stay the same."
>

This is from the docs
https://docs.python.org/3/library/functions.html#id

id(object)

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.

CPython implementation detail: This is the address of the object in memory.

 
---

which may be summarized as:
1. Steven (quoting Online dictionary): Pointer = Address
2. Steven: "Python has pointers" is ridiculous
3. Python docs: id returns an address in (C)Python

To which we have Chris saying CPython ≠ Python
Which reminds me of another definition
Fig-Leaf: A device for converting poor porn into high art

Even in languages like C with an ISO standard adhering to the standard is
academic (gcc's switch is --pedantic) and it is in practice major 
implementations like gcc and MSC that define and push the standard.

In python, CPython is the standard and other implementations can lay claim to
being 'python' to the extent that they adhere to the standard.

Or have I missed some ISO-ization?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Ned Batchelder]

On Saturday, September 12, 2015 at 7:15:18 PM UTC-4, Mark Lawrence wrote:
> On 12/09/2015 23:34, rurpy--- via Python-list wrote:
> > On 09/12/2015 04:14 PM, Emile van Sebille wrote:
> >> On 9/12/2015 12:58 PM, rurpy--- via Python-list wrote:
> >>
> >>> The question is whether what "pointer" means in languages that use the
> >>> word is*so*  different than its meaning in the Python sense
> >>
> >> I can't find a single reference to pointer in the python docs outside
> >> of ctypes.  What is its python sense?
> >
> > I should have said "proposed sense" (except I don't really mean
> > proposed as in "let's change all the docs" but as "let's stop the
> > hissy-fits when someone uses the term"), i.e. the way I, I think
> > random832, and others use it re python. Sorry, I see in retrospect
> > my phrasing could be confusing.
> >
> 
> The "hissy-fits" are caused because Python the language does not have 
> pointers, so by definition there is no need to mention them in any way, 
> shape or form in any Python thread.  What is so difficult to understand 
> about that?  I would say it's not rocket science, but the insurers that 
> paid out over Ariane 5 maybe wouldn't be too happy with that.
> 
> -- 
> My fellow Pythonistas, ask not what our language can do for you, ask
> what you can do for our language.
> 
> Mark Lawrence

After all the discussion here, it seems a bit disingenuous to flatly say
that Python has no pointers, and to dismiss people's debate about it.

Pointers are not a simple concept.  In a language like C, they have a 
number of aspects, some of which are apparent in the Python world, and
some of which are not.

Python names refer to values, and this behavior is clearly related to
pointers under the hood.  Whatever Python implementation you are talking
about, a Python name must have some way to indicate what value it refers
to.  In CPython, this is implemented with a pointer.  This is what people
mean when they say that of course Python has pointers.

But in C, pointers mean more than that.  You can perform arithmetic on
them, to access memory as a linearly addressed abstraction.  Python has
nothing like this.

In C, a pointer can refer to another variable.  Again, Python has
nothing like this.  Python names refer to values, but they cannot
refer to other names.

These last two reasons are why people say that Python does not have
pointers.

As a language concept, Python has no pointers, because you cannot have
names referring to names, and because you cannot perform arithmetic on
references.  The references from names to values are not things that can
be manipulated themselves.

In its implementation, CPython uses pointers.  But if you say that Python
has pointers because CPython uses pointers, then you might as well say
that Python is statically typed because the CPython source has type
declarations.  It's a confusion of implementation and language to conflate
these two.

--Ned.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Chris Angelico]

On Sun, Sep 13, 2015 at 3:24 AM, Steven D'Aprano  wrote:
> Note: when I write my own Python implementation, all IDs will be negative
> odd numbers.

When I build my own CPU architecture, all memory addresses will be
negative odd numbers, so people think your Python uses addresses
again.



ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Random832]

Jussi Piitulainen  writes:
> I think the best way is to say that a[0] and a[1] are the same object,
> while b[0] and b[1] are different objects.

Sure, you can *say* that. But how do you draw it on a diagram with
sticky notes or parcel tags or whatever?

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[rurpy--- via Python-list]

Picking a post to respond to, more or less at random...

On Saturday, September 12, 2015 at 9:14:00 AM UTC-6, Rustom Mody wrote:
> On Saturday, September 12, 2015 at 8:11:49 PM UTC+5:30, Laura Creighton wrote:
> > In a message of Sat, 12 Sep 2015 05:46:35 -0700, Rustom Mody writes:
> > >How about lay-English ontology in which "point to" and "refer to" are 
> > >fairly
> > >synonymous?
> > 
> > This I have found is important in teaching, which is why I favour 'bind'
> > and 'binding' -- rather than pointer, pointer, refer to, referring.
> 
> Well we can play humpty dumpty and make any word mean whatever we like.
> However if you are a teacher you will recognize a need for pictures.
> And (as far as I can tell) "Random832" finds a need for the box-n-arrow
> diagrams of classic data-structure books

*The* python data model is a concept that, like all concepts, exist in
human brains. It (and its related terminology) are descriptions agreed
upon by a majority of Python developers, documentors and others.  Its 
purpose is to explain in a simpler way the behavior of a running Python 
program. [*]

It is only one of many possible descriptions. Its value is measured in
how well and efficiently it allows Python programmers to predict the 
behavior of a Python program. I never found its presentation in the
Python documentation very understandable or helpful.

Having programmed in C in the past, the model of Python I eventually 
developed is very much (I think, haven't read the whole thread) like 
Random832's.  I think of boxes (objects) with slots containing "pointers"
that "point" to other boxes.  Even today when dealing with complex 
Python data structures, I draw boxes and arrows to help me understand
them and think of the arrows as "pointers".

Frankly, I feel a little insulted by people who presume that having 
learned what a pointer is in C, that my brain is so rigid that I must 
necessarily think that pointer means exactly what pointer means in C
forever after.  FYI (the general you), I am capable of extracting the 
general principle and applying it to Python.  Not just capable, but 
using the concept from C made understanding Python faster than pretending
that somehow Python has some magical and unique way of structuring data
that's brand new.

Maybe pedagogical research will show that one particular model is more
easily understood by python learners that some other model. But please
keep in mind that learners come in many varieties and that one size will
not fit all. Knowing what a pointer is in C and applying the concept to
model python worked well for me and I would have no hesitation offering 
it as an explanation to others as an option to help someone else's 
understanding if they, like me, find the official model less then 
helpful.


[*] There is also possibly a "data model" used in specifying the 
Python language for implementors but this thread seems to be about
how to describe Python's behavior to users. 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Steven D'Aprano]

On Sun, 13 Sep 2015 02:54 am, Rustom Mody wrote:

> This is from the docs
> https://docs.python.org/3/library/functions.html#id

Yes, what of it? What point do you think you are making?


> id(object)
> 
> 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.
> 
> CPython implementation detail: This is the address of the object in
> memory.

What part of "CPython implementation detail" was too difficult for you to
understand?

id() is not an addressof function. It returns, and I quote:

"an integer which is guaranteed to be unique and constant for this object
during its lifetime"

which is *not the case for memory addresses*. Here are the IDs of a few
objects in Python:

steve@orac:~$ jython -c "print id(None); import sys; print id(sys)"
1
2

steve@orac:~$ ipy -c "print id(None); import sys; print id(sys)"
0
43


Are you going to argue that these are memory addresses? If not, what
relevance do you think the id() function has here?

Note: when I write my own Python implementation, all IDs will be negative
odd numbers.


-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Steven D'Aprano]

On Sun, 13 Sep 2015 03:12 am, Rustom Mody wrote:


> Best I can see, the people frothing at the mouth that python has no
> pointers are basically saying that "non-first-class" == "non-existent"

Not at all. In Python, at least, all values are first-class, but that's not
the case with all languages which lack pointers. Java has classes but they
aren't first-class values. They aren't values at all, but they do exist as
entities in Java code. You don't have to drop out of Java into some
underlying implementation language in order to write Java classes.

I trust that you agree that Fortran lacks pointers -- or at least, old
versions of Fortran, like FORTRAN 5 and (by memory) Fortran 77 lack them.
(Modern Fortran almost certain has pointers.) Old versions of Fortran lacks
dynamic memory management, it has no pointers, no equivalent of
Pascal's "new" and "dispose". It also has a variable model like C's (named
variables with fixed memory locations).

Suppose I write a Fortran 77 compiler in C. I daresay I would use C's
ability to dynamically allocate and free memory (i.e. pointers) in my
implementation of Fortran 77. But because this is a faithful implementation
of the Fortran 77 standard, warts and all, the Fortran compiler itself
won't have the ability to create, dereference or free pointers.

Would you insist that Fortran 77 has pointers just because my implementation
uses pointers under the hood?



> By that same logic C has neither types nor functions

No. C has both types and functions. You can define your own types, and you
can define your own functions.

They might not be first-class values, but they are entities you manipulate
in your C code. You don't have to drop out of the C language into (say)
machine code to write a function.

In Python, the language *lacks pointers altogether*. It's not just that you
can't treat them as first-class values, or that they aren't values, but
that they aren't even entities in the Python programming model. In order to
interact with pointers, you have to drop out of Python altogether, and
start programming in the implementation language C, or use an interface to
C such as ctypes.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[rurpy--- via Python-list]

On 09/12/2015 04:14 PM, Emile van Sebille wrote:
> On 9/12/2015 12:58 PM, rurpy--- via Python-list wrote:
> 
>> The question is whether what "pointer" means in languages that use the
>> word is*so*  different than its meaning in the Python sense
> 
> I can't find a single reference to pointer in the python docs outside
> of ctypes.  What is its python sense?

I should have said "proposed sense" (except I don't really mean
proposed as in "let's change all the docs" but as "let's stop the
hissy-fits when someone uses the term"), i.e. the way I, I think
random832, and others use it re python. Sorry, I see in retrospect
my phrasing could be confusing.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Chris Angelico]

On Sun, Sep 13, 2015 at 2:54 AM, Rustom Mody  wrote:
>> Insisting that Python has pointers is like insisting that you use a text
>> editor by flipping bits. "What happens if I press Ctrl-X?" "Well, these
>> bits on the screen flip from black to white, these bits flip from white to
>> black, and these stay the same."
>>
>
> This is from the docs
> https://docs.python.org/3/library/functions.html#id
>
> id(object)
>
> 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.
>
> CPython implementation detail: This is the address of the object in 
> memory.

*Python* does not have addresses. *CPython* is an implementation of
the Python language which uses memory. Jython uses Java objects, and
thus doesn't have memory addresses. PyPy doesn't keep things at fixed
locations in memory, and maintains a separate concept of object
identities, even though it is implemented using some form of system
memory.

Python does not have pointers or addresses.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Rustom Mody]

On Saturday, September 12, 2015 at 10:21:08 PM UTC+5:30, Steven D'Aprano wrote:
> Python values are not addresses. Python values are objects.

Which means for example...???
Atoms? Stars? People? Countries?


> Addresses, even when they exist, are not accessible in the Python language.
And you claim that these addresses are less accessible to python than the 
objects above?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[rurpy--- via Python-list]

On 09/12/2015 11:48 AM, Steven D'Aprano wrote:
> On Sun, 13 Sep 2015 02:17 am, ru...@yahoo.com wrote:
> [...]
>> the model of Python I eventually 
>> developed is very much (I think, haven't read the whole thread) like
>> Random832's.  I think of boxes (objects) with slots containing "pointers"
>> that "point" to other boxes.  Even today when dealing with complex
>> Python data structures, I draw boxes and arrows to help me understand
>> them and think of the arrows as "pointers".
> 
> If you're going to abuse terminology, why don't you call the boxes "floats"
> since they "float around in memory",
> [...]

I was not proposing that, I was talking about the use of the term
"pointer".

> C is not the only, or even the first, language to have standardised on a
> meaning for pointer in computer science. Pascal had pointers long before C,
> and I'm sure Pascal wasn't the first either.

[I'm not sure about the "long before" part given they were nearly
contemporaneous.]

Right, and each of them uses the word (and others like "function", "call"
"arguments", etc) in their own specific way, which they define as part
of the description of the language. "function" in C is different than
"function" in Pascal which is different than "function" in Python.

That C (or Pascal) used the term first does not mean that it was
"standardized" by that use to have that precise definition forever after.

> "Pointer" is a standard primitive data type across dozens of languages: it's
> an abstract data type holding the memory address of a variable (either a
> named, statically allocated variable, or more often, an anonymous,
> dynamically allocated variable). As such, it requires that variables have a
> fixed address. If the variable can move, the pointer will no longer point
> to the variable.

See my comments on "fixed address" in another post.  Your definition of
"address" is too narrow.

> If you want to use "pointer" to refer to something else, the onus is on you
> to make it clear that you're using it in a non-standard way.

Of course. Nobody should ever say (a least formally) just "pointer" and
expect the entire (assumed diverse) audience to have a common single 
understanding of what is meant. But that applies to most terminology 
like "reference" as well.  It is why language documentation has things 
like definitions and glossaries.

> Some day, most programmers will be using nothing by dynamic languages which
> lack pointers-the-data-type,

I don't think there is any direct relationship between pointers and
dynamic languages. Go is not a dynamic language yet it does not not
allow unrestrained pointer use a'la C.

My impression is that unmanaged pointers (in the C sense) are recognized
these days as dangerous and that nearly all new languages including static
ones manage "pointers" (perhaps under a different name) to prevent the
problems that occur with C.

> and the term will lose its baggage and can be
> safely used as a generic English term for "a thing which points". The tiny
> minority of systems programmers writing device drivers and kernel code in
> Rust (C having been long-since delegated to the wastebin of history -- well
> that's my fantasy and I'm sticking to it)

That's fine, so we are talking about the far distant future, maybe
year 3000 or so. :-)

> will learn that, outside of their
> own niche, "pointer" does not have the technical meaning that they are used
> to, and everyone else will be as blissfully unaware of said technical
> meaning as the average programmer today is of continuations and futures.
> 
> But this is not that day.

I think you underestimate the ability of human beings (even programmers)
to interpret words in a context dependent way.
 
The question is whether what "pointer" means in languages that use the
word is *so* different than its meaning in the Python sense, that using
it for Python is more misleading than helpful. You think so, perhaps
because you focus on the unmanaged and memory-address aspects of its use.
I consider those as non-determining characteristics of a thing that points
to something and instead consider its pointingness to be its defining
characteristic, in those languages and in Python, and thus find it 
perfectly descriptive for Python.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Jussi Piitulainen]

Rustom Mody writes:

 a
> [[1,2],[1,2]]
 b
> [[1,2],[1,2]]
> And yet doing
 a[0][0] = "Oops!"
> gives a data structure one "Oops!"
> whereas doing it to b mysteriously gives 2
>
> Best I can see you can only explain this 
> seemingly-similar-but-structurally-different
> with box-n-arrow diagrams.
> Or some moral equivalent.

I think the best way is to say that a[0] and a[1] are the same object,
while b[0] and b[1] are different objects. Possibly b[0] is also the
same object as a[0] and a[1]. Then b[0][0] = "Oops!" was redundant.

And the way to work out whether two objects are the same is to trace
where they come from. Certain pieces of code result in new objects.
Other pieces of code pass old objects around. Possibly store them in
places, or change them in some way. Never make copies.

Works for me.

Some sort of pointer-talk is useful to discuss the implementation of all
this (how can an object be in different places? how does an arbitrary
object fit in a 64-bit register?) but for ordinary reasoning about a
program, pointer-talk with those diagrams mostly gets in the way.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Akira Li]

Rustom Mody  writes:

> On Saturday, September 12, 2015 at 11:26:18 PM UTC+5:30, Akira Li wrote:
>> Rustom Mody  writes:
>> 
>> > On Saturday, September 12, 2015 at 8:11:49 PM UTC+5:30, Laura Creighton 
>> > wrote:
>> >> In a message of Sat, 12 Sep 2015 05:46:35 -0700, Rustom Mody writes:
>> >> >How about lay-English ontology in which "point to" and "refer to" are 
>> >> >fairly
>> >> >synonymous?
>> >> 
>> >> This I have found is important in teaching, which is why I favour 'bind'
>> >> and 'binding' -- rather than pointer, pointer, refer to, referring.
>> >
>> > Well we can play humpty dumpty and make any word mean whatever we like.
>> > However if you are a teacher you will recognize a need for pictures.
>> > And (as far as I can tell) "Random832" finds a need for the box-n-arrow
>> > diagrams of classic data-structure books
>> 
>> Speaking of pictures and names in Python
>> http://python.net/~goodger/projects/pycon/2007/idiomatic/handout.html#other-languages-have-variables
>
> Yeah cute
> [I think I will even use these in my classes]
> However they dont address the issue that I think random832 is
> referring to.

The pictures despite their simplicity reflect the actual model that
Python language uses i.e., any deviations are an implementation artifact
and may be ignored.

> viz. I have two variables (or names!) say a and b which look the same
 a
> [[1,2],[1,2]]
 b
> [[1,2],[1,2]]
> And yet doing
 a[0][0] = "Oops!"
> gives a data structure one "Oops!"
> whereas doing it to b mysteriously gives 2

Sorry, I haven't followed the whole thread. Could your provide a
complete code example? Mention what you expect to happen and what
happens instead in your case.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Emile van Sebille]

On 9/12/2015 12:58 PM, rurpy--- via Python-list wrote:


The question is whether what "pointer" means in languages that use the
word is*so*  different than its meaning in the Python sense


I can't find a single reference to pointer in the python docs outside of 
ctypes.  What is its python sense?


Is-there-no-hammer-in-this-toolbox-ly y'rs

Emile


--
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: “reference” versus “pointer”

[Steven D'Aprano]

On Sat, 12 Sep 2015 03:03 pm, Random832 wrote:

> Yes I am. You're just making the implicit assumption that a "value" has
> to be a number, and I was ignoring that assumption. The value is the
> address of an object.

The unknown, unknowable, and in fact possibly non-existent address of an
object. There is nothing about the Python language which demands that
objects have addresses. We could build a Python interpreter using a giant
clockwork mechanical computing machine, like the Difference Engine only
much more complex, and it would not have addressable objects.

If you would prefer a more practical counter-example, we can simulate a
Python interpreter in our head (at least for short programs). Again, there
is no addressable memory in the human brain, and hence the objects have no
address.

But for the sake of the argument, let's suppose you are right, and that
Python values are "the address of the object".

Given:

x = "blue cats eat green mice"

I would say that the value of x is the string "blue cats eat green mice".

You, apparently, believe that the value of x is 0xb7aea480. Or possibly
0xb43384aa. Or whatever address the interpreter happens to give you on this
specific run of your program.

This abuse of the word "value" is sheer balderdash. To quote Fredrik Lundh:

well, I guess you can, in theory, value an artificial number
assigned to an object as much as the object itself.
   
"Joe, I think our son might be lost in the woods"
"Don't worry, I have his social security number"

http://effbot.org/zone/call-by-object.htm.

Python values are not addresses. Python values are objects. Addresses, even
when they exist, are not accessible in the Python language.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Emile van Sebille]

On 9/12/2015 9:54 AM, Rustom Mody wrote:

On Saturday, September 12, 2015 at 10:02:40 PM UTC+5:30, Steven D'Aprano wrote:

On Sat, 12 Sep 2015 02:42 pm, Random832 wrote:


Anyway, maybe we do need a term to distinguish Python/C#/Java pointers
from C/C++ pointers - maybe call it a "non-arithmetic" pointer, since
the key thing about it is you can't do pointer arithmetic on them to get
the object "next to" the one it points at.


How about *just don't call them pointers*? You know, since they aren't
pointers in the computer science sense.

The Free On-line Dictionary of Computing defines "pointer":

1.  An address, from the point of view of a
programming language.  A pointer may be typed, with its type
indicating the type of data to which it points.





Insisting that Python has pointers is like insisting that you use a text
editor by flipping bits. "What happens if I press Ctrl-X?" "Well, these
bits on the screen flip from black to white, these bits flip from white to
black, and these stay the same."



This is from the docs
https://docs.python.org/3/library/functions.html#id

id(object)

 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.

 CPython implementation detail: This is the address of the object in memory.


Quoting from above:

>> The Free On-line Dictionary of Computing defines "pointer":
>>
>> 1.  An address, from the point of view of a
>> programming language.

So, how does the CPython program access the contents given its 'address 
in memory'?  From the definition it would seem it's not a pointer, as 
from the perspective of the programming language, you can't get there 
from the id.


Look-ma,-no-pointers-ly y'rs,

Emile



--
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Rustom Mody]

On Saturday, September 12, 2015 at 10:38:46 PM UTC+5:30, Steven D'Aprano wrote:
> On Sat, 12 Sep 2015 10:46 pm, Rustom Mody wrote:
> 
> > On Saturday, September 12, 2015 at 11:57:01 AM UTC+5:30, Ben Finney wrote:
> 
> >> You've clearly committed to some ontology that just doesn't match the
> >> Python data model.
> > 
> > How about lay-English ontology in which "point to" and "refer to" are
> > fairly synonymous?
> 
> "Pointer" in English is also a synonym for 
> 
> - a type of dog;
> - an instrument which pierces (as used by engravers, lace workers, etc); 
> - an item of private information; 
> - a hint or tip; 
> - a caution or warning; 
> - a recommendation; 
> - the index finger; 
> - a cricketer fielding at a specific position; 
> - the hour/minute/second hand on a timepiece; 
> - a compass needle; 
> - two specific stars in the constellation of the Great Bear (Ursa Major);
> -  diagonal braces fastened across the hold of a ship;
> - the small icon whose movement across the screen follows that of the 
>   mouse, trackball or other pointing device; 
> - a signpost or milepost; 
> 
> and more. I don't think that arguing on the basis of lay-English or plain
> English terms is going to be terribly useful.

So if someone's ontology disagrees with yours its not very useful.
You're welcome to that view of course
Its called "Humpty-Dumpty" (in Alice ontology).

We could have had a more 'useful' discussion if alongside the meanings of 
"pointer" you had provided meanings of "reference" as well
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: “reference” versus “pointer”

[Steven D'Aprano]

On Sat, 12 Sep 2015 02:42 pm, Random832 wrote:

> Anyway, maybe we do need a term to distinguish Python/C#/Java pointers
> from C/C++ pointers - maybe call it a "non-arithmetic" pointer, since
> the key thing about it is you can't do pointer arithmetic on them to get
> the object "next to" the one it points at.

How about *just don't call them pointers*? You know, since they aren't
pointers in the computer science sense.

The Free On-line Dictionary of Computing defines "pointer":

   1.  An address, from the point of view of a
   programming language.  A pointer may be typed, with its type
   indicating the type of data to which it points.


Arithmetic is irrelevant to the definition of "pointer". That's a foible of
C, not fundamental to the concept of pointer. Pascal, for example, has
pointers too, implemented pretty much in the same way as C/C++, but the
type system doesn't allow you to perform arithmetic on them because they
aren't treated as integers.


Computer science and IT is *dominated* by a single usage for "pointer" --
it's an abstract memory address. The fundamental characteristics of
pointers are:

- they are first-class values; you can assign a pointer to a variable;

- you can dereference a pointer: get the value pointed to;

- (in some languages) you can get a pointer to a specific variable (possibly
an unnamed, dynamic variable allocated in the heap rather than a named,
statically allocated variable).


The last two imply that the language must be one where values have fixed
addresses, not just as a matter of implementation, but as a matter of
language semantics. If they are free to move, they cannot have a fixed
address.

Python, Java, Ruby, Lua, Javascript etc. have *no such concept* as pointer.
There are no values in these languages which correspond to the standard
definition of pointer:

- you cannot get a pointer to an object or a variable (a name);

- since there are no pointers, you cannot dereference them;

- or assign them to a variable.


Since pointers can be considered an indirect reference to a value, what sort
of indirect references does Python have? The simplest thing in Python that
is somewhat analogous to a pointer is a *name*, since names allow you to
indirectly refer to some value:

x = 23
print(x)  # prints the value referred to by x, not "x" itself.
ptr = "x"  # equivalent to "the address of x"
y = globals()[ptr]  # equivalent to dereferencing


Note that names are not first-class values in Python: there is no Name type,
and you cannot bind a name to a variable, you have to use a string.

It's not a very close analogy, but it's the closest Python has.


Implementations of Python, Javascript, Lua, Java, Ruby etc. *may or may not*
use pointers in the implementation, but they are not part of the language
interface. These languages have no "addressof" operator, no dereference
operator, and no "pointer" type; values do not necessarily have fixed
addresses (indeed, in Jython and IronPython, values can move in memory).

Insisting that Python has pointers is like insisting that you use a text
editor by flipping bits. "What happens if I press Ctrl-X?" "Well, these
bits on the screen flip from black to white, these bits flip from white to
black, and these stay the same."




-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[rurpy--- via Python-list]

On 09/12/2015 06:02 PM, Ned Batchelder wrote:
> On Saturday, September 12, 2015 at 7:15:18 PM UTC-4, Mark Lawrence wrote:
> [...]
> But in C, pointers mean more than that.  You can perform arithmetic on
> them, to access memory as a linearly addressed abstraction.  Python has
> nothing like this.
> 
> In C, a pointer can refer to another variable.  Again, Python has
> nothing like this.  Python names refer to values, but they cannot
> refer to other names.
> 
> These last two reasons are why people say that Python does not have
> pointers.
> 
> As a language concept, Python has no pointers, because you cannot have
> names referring to names, and because you cannot perform arithmetic on
> references.  The references from names to values are not things that can
> be manipulated themselves.

The reason python doesn't have pointers is that the majority of developers
and documenters chose not to use the term.

I don't see that pointer arithmetic is necessary to call something a pointer
(and i think someone else said the same earlier). And references to a name
I think that is an artifact of C because in C names and values are inextricably
welded together at compile time -- a pointer to a name is also necessarily a
pointer to a value. Since there are no C pointers to don't point to values
they can provide a way to describe Python "things" that also point to values.

If one acknowledges that those two properties are not intrinsic requirements
for pointerness then describing the things "in" a python object that are used
to identify and dereference other objects, as pointers is not at all 
unreasonable.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[rurpy--- via Python-list]

On Saturday, September 12, 2015 at 6:25:39 PM UTC-6, ru...@yahoo.com wrote:
> On 09/12/2015 05:39 PM, Rustom Mody wrote:
> [...]
> > which may be summarized as:
> > 1. Steven (quoting Online dictionary): Pointer = Address
> > 2. Steven: "Python has pointers" is ridiculous
> > 3. Python docs: id returns an address in (C)Python
> > 
> > To which we have Chris saying CPython ≠ Python
> > [...]
> I have to agree with Steven and Chris here. 
> [...]

I'm writing too fast.  Just to clarify, I don't of course agree that
python doesn't have pointers (or something that can be labeled as
such), just that the existence of id() and cpython's internal use 
of pointers are not good arguments that it doesn't.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[rurpy--- via Python-list]

On 09/12/2015 05:14 PM, Mark Lawrence wrote:
> On 12/09/2015 23:34, rurpy--- via Python-list wrote:
>> On 09/12/2015 04:14 PM, Emile van Sebille wrote:
>>> On 9/12/2015 12:58 PM, rurpy--- via Python-list wrote:
>>> 
 The question is whether what "pointer" means in languages that
 use the word is*so*  different than its meaning in the Python
 sense
>>> 
>>> I can't find a single reference to pointer in the python docs
>>> outside of ctypes.  What is its python sense?
>> 
>> I should have said "proposed sense" (except I don't really mean 
>> proposed as in "let's change all the docs" but as "let's stop the 
>> hissy-fits when someone uses the term"), i.e. the way I, I think 
>> random832, and others use it re python. Sorry, I see in retrospect 
>> my phrasing could be confusing.
> 
> The "hissy-fits" are caused because Python the language does not have
> pointers, so by definition there is no need to mention them in any
> way, shape or form in any Python thread.

Right. "And our country has no social unrest so there is no need
for any mention of social unrest on our internet." (a common
justification for censorship in some countries.) You can't define
away reality, Bucky.

But the issue is not one that can be expressed as a binary "has" or
"has not". It is about how to best describe how Python works and
what descriptions work best for what groups of people (at least in
my view).

> What is so difficult to understand about that?

You'll find my questions about that in my previous posts. You
can find them here:
https://mail.python.org/pipermail/python-list/2015-September/thread.html
If you have any specific serious questions I'll be happy to try
to answer them for you.

> I would say it's not rocket science, but the
> insurers that paid out over Ariane 5 maybe wouldn't be too happy with
> that.

No clue what the Ariane 5 has to do with Python or how Python
works is described.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Rustom Mody]

On Sunday, September 13, 2015 at 5:32:44 AM UTC+5:30, Ned Batchelder wrote:
> In its implementation, CPython uses pointers.  But if you say that Python
> has pointers because CPython uses pointers, then you might as well say
> that Python is statically typed because the CPython source has type
> declarations.  It's a confusion of implementation and language to conflate
> these two.

Yes that "because" can be ridiculous/disingenuous.
Good deal of it in this thread itself.

Consider int.
Say there are 10,000
int something_or_other;
in the CPython sources

Out of these say 50 are the direct implementation python's int
The remaining 9950 C-ints have no direct correlate with python's int.

The disingenuous reasoning is some kind of statistical argument of 10,000 vs 50.
The reasonable reasoning is that only those 50 are relevant to the discussion.

Likewise pointers

If one were to trace the semantics of looking up a variable in CPython,
one would find some C code doing pointer dereferencing.

One would also find zillions of other uses of pointers that have no direct
correlate to python's variables.

What of it?

If I were to be more technically correct than saying
"Python's variables are C-pointers"

I could say something like:

"Python variables are C pointers with much stronger data-structure 
invariants related to ownership. And implemented with ref-counting, gc etc
as scaffolding to ensure them.  These stronger invariants make impossible in 
python common C errors like null-pointer referencing. The corresponding cost
of these stronger invariants is that C's pointer type is rendered 
un-first-class in python"
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Ben Finney]

Rustom Mody  writes:

> On Saturday, September 12, 2015 at 11:57:01 AM UTC+5:30, Ben Finney wrote:
> > You've clearly committed to some ontology that just doesn't match
> > the Python data model.
>
> How about lay-English ontology in which "point to" and "refer to" are fairly
> synonymous?

That's important. It's unrelated, though, to the very specific technical
programming concepts to which I was responding.

-- 
 \  “One bad programmer can easily create two new jobs a year. |
  `\  Hiring more bad programmers will just increase our perceived |
_o__) need for them.” —David Lorge Parnas, 1999-03 |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Ben Finney]

Michael Torrie  writes:

> On 09/12/2015 08:22 PM, Mark Lawrence wrote:
> > You appear to have the same level of knowledge of Python internals as 
> > the RUE has of the Python 3.3+ FSR unicode implementation.  Let's have 
> > some fun, is Python pass by value or pass by reference?  It has to be 
> > more interesting debating that than the drivel that's gone before in 
> > this thread.
>
> Oh you are a devious one there! This should get good.

No, it should stop there. Taunting trolls is no more welcome here than
trolling.

-- 
 \   “I have always wished for my computer to be as easy to use as |
  `\   my telephone; my wish has come true because I can no longer |
_o__)  figure out how to use my telephone.” —Bjarne Stroustrup |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Steven D'Aprano]

On Sun, 13 Sep 2015 07:10 am, Random832 wrote:

> Jussi Piitulainen  writes:
>> I think the best way is to say that a[0] and a[1] are the same object,
>> while b[0] and b[1] are different objects.
> 
> Sure, you can *say* that. But how do you draw it on a diagram with
> sticky notes or parcel tags or whatever?

However you like. Invent your own notation. A few suggestions:


Colour coding:

Have a convention that objects drawn in black imply that object identity is
not important. That is, if you have two boxes drawn in black with the same
value, you are making no claim one way or the other whether they are the
same object or not. If, and only if, identity is important, then you give
each object a unique colour. So if the user sees five boxes containing the
value "foo", two in red, two in green, and one in black, they know that
there are at least two, and possibly three, but no more than three,
individual objects.

Shapes:

Likewise, except instead of colour, use the shape of the box to indicate
identity. A rectangular box means you say nothing about identity. Other
shapes (circle, oval, rhombus, trapezium, parallelogram, cloud-shape, etc.)
uniquely represents the individual objects.

IDs:

Write the object ID on each box, or at least the boxes where identity is
important. A good convention is that IDs start at 1.

Or, rather than show a numeric ID, use a symbolic ID: a, b, c, d, e would
reference five distinct objects.

Or, use non-alphabetical symbolic IDs: *†‡ would let you identify three
distinct objects. Add extra symbols as needed.


Astral travel:

According to those who believe in the astral plane, when you travel through
the astral plane, a silver thread connects your physical body to your
astral body. Or your earthly soul to your astral soul. Or whatever it is
that they believe. Use the same symbolism: if you have two or more boxes
representing the same object in different places, join them with a silver
thread. Or other colour of your choice. Perhaps a dotted or dashed line.

Hatch marks:

There is a convention in geometry to indicate lines of equal length with a
hatch mark (a small line perpendicular to the line itself). You can mark
the boxes which refer to identical objects using a similar convention.

Here is a crappy ASCII-art representation of various hatch marks on a
horizontal line:

||||||///\\\XXX><

That is, reading from left to right:

- 1 to 3 vertical lines; 
- 1 or 2 lines slanted up to the right; 
- 1 or 2 lines slanted down from the left;
- 1 or 2 crossed lines;
- single right-pointing arrow;
- single left-pointing arrow.


If you limit yourself to no more than four hatch marks, taken from the set
of "|/\X<>", that gives you 1554 distinct markers. If you need to identify
more than 1554 distinct objects on one diagram, I suggest your diagram is a
tad too complex.



-- 
Steven

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Michael Torrie]

On 09/12/2015 08:22 PM, Mark Lawrence wrote:
> You appear to have the same level of knowledge of Python internals as 
> the RUE has of the Python 3.3+ FSR unicode implementation.  Let's have 
> some fun, is Python pass by value or pass by reference?  It has to be 
> more interesting debating that than the drivel that's gone before in 
> this thread.

Oh you are a devious one there! This should get good.




-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Ned Batchelder]

On Saturday, September 12, 2015 at 10:23:24 PM UTC-4, Mark Lawrence wrote:
> On 13/09/2015 01:44, rurpy--- via Python-list wrote:
> > On 09/12/2015 06:02 PM, Ned Batchelder wrote:
> >> On Saturday, September 12, 2015 at 7:15:18 PM UTC-4, Mark Lawrence wrote:
> >> [...]
> >> But in C, pointers mean more than that.  You can perform arithmetic on
> >> them, to access memory as a linearly addressed abstraction.  Python has
> >> nothing like this.
> >>
> >> In C, a pointer can refer to another variable.  Again, Python has
> >> nothing like this.  Python names refer to values, but they cannot
> >> refer to other names.
> >>
> >> These last two reasons are why people say that Python does not have
> >> pointers.
> >>
> >> As a language concept, Python has no pointers, because you cannot have
> >> names referring to names, and because you cannot perform arithmetic on
> >> references.  The references from names to values are not things that can
> >> be manipulated themselves.
> >
> > The reason python doesn't have pointers is that the majority of developers
> > and documenters chose not to use the term.
> 
> Nonsense.
> 
> 
> You appear to have the same level of knowledge of Python internals as 
> the RUE has of the Python 3.3+ FSR unicode implementation.  Let's have 
> some fun, is Python pass by value or pass by reference?  It has to be 
> more interesting debating that than the drivel that's gone before in 
> this thread.

Mark, I'm sure you can be more respectful than this.

And let's please not start down the "PBV or PBR" road... :(

--Ned.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[rurpy--- via Python-list]

On 09/12/2015 05:39 PM, Rustom Mody wrote:
> On Sunday, September 13, 2015 at 4:05:21 AM UTC+5:30, ru...@yahoo.com wrote:
>> On 09/12/2015 04:14 PM, Emile van Sebille wrote:
>>> On 9/12/2015 12:58 PM, rurpy--- via Python-list wrote:
>>>
 The question is whether what "pointer" means in languages that use the
 word is*so*  different than its meaning in the Python sense
>>>
>>> I can't find a single reference to pointer in the python docs outside
>>> of ctypes.  What is its python sense?
>>
>> I should have said "proposed sense" (except I don't really mean
>> proposed as in "let's change all the docs" but as "let's stop the
>> hissy-fits when someone uses the term"), i.e. the way I, I think
>> random832, and others use it re python. Sorry, I see in retrospect
>> my phrasing could be confusing.
> 
> Here is my post a little way up:
> 
> ---
> On Saturday, September 12, 2015 at 10:02:40 PM UTC+5:30, Steven D'Aprano 
> wrote:
> [...]
>> Insisting that Python has pointers is like insisting that you use a text
>> editor by flipping bits. "What happens if I press Ctrl-X?" "Well, these
>> bits on the screen flip from black to white, these bits flip from white to
>> black, and these stay the same."
> 
> This is from the docs
> https://docs.python.org/3/library/functions.html#id
> 
> id(object)
> 
> 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.
> 
> CPython implementation detail: This is the address of the object in 
> memory.
> 
> ---
> 
> which may be summarized as:
> 1. Steven (quoting Online dictionary): Pointer = Address
> 2. Steven: "Python has pointers" is ridiculous
> 3. Python docs: id returns an address in (C)Python
> 
> To which we have Chris saying CPython ≠ Python
> Which reminds me of another definition
> Fig-Leaf: A device for converting poor porn into high art
> 
> Even in languages like C with an ISO standard adhering to the standard is
> academic (gcc's switch is --pedantic) and it is in practice major 
> implementations like gcc and MSC that define and push the standard.
> 
> In python, CPython is the standard and other implementations can lay claim to
> being 'python' to the extent that they adhere to the standard.
> 
> Or have I missed some ISO-ization?

I have to agree with Steven and Chris here. Among other reasons because
although id() allows you to determine if two objects are the same object,
you can't dereference it to get any access to the object. So id() certainly
doesn't give you something I would call a pointer. And though you are right
about cpython's preeminent position, I don't think one can use that to make
an argument about python-the-language unless it can be shown that implementing
it in some other way would be very difficult.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Mark Lawrence]

On 13/09/2015 01:44, rurpy--- via Python-list wrote:

On 09/12/2015 06:02 PM, Ned Batchelder wrote:

On Saturday, September 12, 2015 at 7:15:18 PM UTC-4, Mark Lawrence wrote:
[...]
But in C, pointers mean more than that.  You can perform arithmetic on
them, to access memory as a linearly addressed abstraction.  Python has
nothing like this.

In C, a pointer can refer to another variable.  Again, Python has
nothing like this.  Python names refer to values, but they cannot
refer to other names.

These last two reasons are why people say that Python does not have
pointers.

As a language concept, Python has no pointers, because you cannot have
names referring to names, and because you cannot perform arithmetic on
references.  The references from names to values are not things that can
be manipulated themselves.


The reason python doesn't have pointers is that the majority of developers
and documenters chose not to use the term.


Nonsense.



I don't see that pointer arithmetic is necessary to call something a pointer
(and i think someone else said the same earlier). And references to a name
I think that is an artifact of C because in C names and values are inextricably
welded together at compile time -- a pointer to a name is also necessarily a
pointer to a value. Since there are no C pointers to don't point to values
they can provide a way to describe Python "things" that also point to values.


There are certainly no C pointers in Jython or IronPython but please 
don't let that stop you.




If one acknowledges that those two properties are not intrinsic requirements
for pointerness then describing the things "in" a python object that are used
to identify and dereference other objects, as pointers is not at all 
unreasonable.



You appear to have the same level of knowledge of Python internals as 
the RUE has of the Python 3.3+ FSR unicode implementation.  Let's have 
some fun, is Python pass by value or pass by reference?  It has to be 
more interesting debating that than the drivel that's gone before in 
this thread.


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: “reference” versus “pointer”

[Random832]

Mark Lawrence  writes:

> No it isn't.  When you make a copy of an object you will end up with
> two names that refer to the same object.

No, when you *make a copy of* an object, you get two objects.

>>> x = [1, 2, 3]
>>> y = copy.copy(x)
>>> x is y
False

What you make a copy of when you do y = x is not the object.

> If y was a copy of x, then when x is blown away how can y still know
> about the list that x originally referred to?

Because what is in x, and therefore what is copied when you assign y =
x, *is* the knowledge of how to find the list. Not the list itself. The
object is also not what is deleted when you delete it.

And deleting the original does not delete a copy and I don't even
understand how you can possibly think it could.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: “reference” versus “pointer”

[Chris Angelico]

On Sat, Sep 12, 2015 at 4:26 PM, Ben Finney  wrote:
> If you do agree with those, some corollaries follow:
>
> * Container types do not contain objects.
>
>   It is a useful analogy to say the objects are “in” the container; but
>   that would imply they are not simultaneously in any other container.
>   That's not true, so it's a flawed (though very useful) analogy.

It's so useful that we have an operator called "in", implemented using
a magic method "__contains__", to test exactly that concept. As long
as you understand that containment here really means something more
like "is accessible from", it's correct. Flawed in a minor way, but so
extremely convenient that it's not worth going for complete technical
correctness.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: “reference” versus “pointer”

[Chris Angelico]

On Sat, Sep 12, 2015 at 3:03 PM, Random832  wrote:
>> You can't, for example, keep the old reference (there are no references
>> to references in Python), because they're not accessible as values in
>> themselves. Once you assign a different reference, the old one is gone
>> and can't be found again.
>
> You can keep it by copying it to somewhere. The pointer is the value,
> not the variable, you don't _need_ a reference to it.

CPython happens to implement references using pointers, which leads a
lot of people to think that Python's references are pointers in
disguise. But Python (the language) does not have any concept of
pointers or memory. An integer is not a GNU Multiprecision Bignum
object, it is simply an integer. A string is not a series of bytes in
Latin-1/UCS-2/UCS-4, it is a series of codepoints. Aside from fiddling
around with ctypes (which isn't a supported action), there is nothing
you can do within Python to find out what a reference "is"; there is
literally ONE operation you can do with a reference, and that's to get
at the object it refers to. (For example, you might think that the
'is' operator is comparing two references to see if they point to the
same object. In CPython, it probably is implemented as a pointer
comparison; but actually, it's comparing two objects to see if they're
the same object.)

Python does not have pointers, not because you can't do arithmetic on
those pointers, but because they do not exist in the language spec.
The Python interpreter in my brain, which I use frequently when
diagnosing bugs (whether in my own or someone else's code), does not
have pointers; I'm not prepared to guarantee that it's 100% compliant
with the spec, but I know for sure that it _could be_, without adding
any notion of pointers.

C has pointers, and still would even pointer arithmetic were
disallowed. The languages are architected differently.

(Oh, and an object's identity is a special attribute of that object.
It's not like its location in memory, which is an attribute of the
reference to the object; it's a number that can be retrieved from the
object itself.)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: “reference” versus “pointer”

[Mark Lawrence]

On 12/09/2015 06:42, Random832 wrote:

Ben Finney  writes:

The reference value is inaccessible to the program, it can only be used
to get at the referenced object.


That's like saying an integer is inaccessible since it can only be used
to add/subtract/etc (list of all operations you can do with an
integer). What does it mean to access something, if not to do some
operation on it? Getting the referenced object is the operation you can
do with it.


So in Python, we don't have pointers because we don't have access to
change or reassign them.


Yes you do. That's _exactly what happens_ in an assignment statement -
you are reassigning it to the address of another object. And that's
something you *can't do* with references in C++.


The operation you describe doesn't change the reference; it doesn't
mutate an existing value which can be compared with whatever value it
had before. Instead, it throws away one reference and replaces it with a
different one.


So, if you have a list x, and assign a new value to x[0], it doesn't
change the list, because you can't compare the list to the value the
list had before?


x still refers to a object which in this case happens to be a list. 
You've merely changed the value of the first element of the object that 
is referred to by the name x.




You're not making any sense. It's a value. Changing it and "throwing
away and replacing with a different one" are the same thing.


That's significant, because unlike a mutable value you can never again
get at the old reference in the Python program.


I don't understand what you mean by "can never again get at" it if you
think you _can_ do it for mutable values.


You can't, for example, keep the old reference (there are no references
to references in Python), because they're not accessible as values in
themselves. Once you assign a different reference, the old one is gone
and can't be found again.


You can keep it by copying it to somewhere.


How do you propose to “copy” a reference in Python? Making a new
reference to the referenced object is not making a copy of the
reference.


Yes it is. I don't know why you think it's not, so I can't even figure
out how to respond to this.



No it isn't.  When you make a copy of an object you will end up with two 
names that refer to the same object.


>>> x = [1,2,3]
>>> y = x
>>> x;y
[1, 2, 3]
[1, 2, 3]
>>> del x
>>> y
[1, 2, 3]

If y was a copy of x, then when x is blown away how can y still know 
about the list that x originally referred to?


--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: “reference” versus “pointer”

[Ben Finney]

Random832  writes:

> Ben Finney  writes:
> > The reference value is inaccessible to the program, it can only be
> > used to get at the referenced object.
>
> What does it mean to access something, if not to do some operation on
> it? Getting the referenced object is the operation you can do with it.

You've clearly committed to some ontology that just doesn't match the
Python data model.

The following are some of the axioms in Python's data model:

* All values are objects that persist over time.

* All objects have an immutable identity, that is guaranteed different
  from all other coexisting objects.

* The identity of an object has no particular relationship to the
  object's implementation or location [0], it is an abstract value that
  has no meaning other than uniquely identifying the object.

* The ‘id’ function returns the identity of the object passed as the
  parameter to the call.

* A name used to access an object is a reference to that object,
  equivalent to an item in a dictionary.

* A collection instance — a list, a dict, a set, etc. — contains
  references to objects, and provide access to those references via the
  container type's API.

If you don't agree with those, that's too bad, and it means there's not
much point continuing the discussion. I hope, therefore, that you do
agree with those axioms.

If you do agree with those, some corollaries follow:

* Container types do not contain objects.

  It is a useful analogy to say the objects are “in” the container; but
  that would imply they are not simultaneously in any other container.
  That's not true, so it's a flawed (though very useful) analogy.

* Names do not contain anything.

  They aren't what some other languages call “variables”. They are
  oblivious to the type of the value and can never exist except while
  referencing some object.

* References are not values.

  The reference obviously must have an implementation that deals with
  values, but those values are not available in Python. Each reference
  is inaccessible, hidden away; it is not a value, it is not an object.

> So, if you have a list x, and assign a new value to x[0], it doesn't
> change the list, because you can't compare the list to the value the
> list had before?

Yes, it changes the list. It doesn't change any of the references
themselves.

The list's value is the sequence of references it contains. Removing one
reference changes the list's value; putting a different reference in the
collection changes the list's value.

None of that changes any reference, it just changes *which* references
are in the list.

The references themselves don't have any value accessible to Python.

> You're not making any sense. It's a value. Changing it and "throwing
> away and replacing with a different one" are the same thing.

Not true. To throw away one and replace it with another is to switch to
a different value with a different identity::

>>> foo = 17 # One reference to the integer object.
>>> bar = foo# A different reference to the object.
>>> id(foo) == id(bar)# Are these references to the same object?
True
>>> bar = 9   # Try to “change” the object.
>>> id(foo) == id(bar)# Is ‘bar’ still the same object?
False

To change a value is to keep the same identity::

>>> foo = [17, 23, 42]# One reference to the list object.
>>> bar = foo # A different reference to the object.
>>> id(foo) == id(bar)# Are these references to the same object?
True
>>> id(foo[2]) == id(bar[2])  # How about the references contained in the 
list?
True
>>> bar[2] = 9# Try to “change” the object.
>>> id(foo) == id(bar)# Is ‘bar’ still the same object?
True

References aren't values, so their identity doesn't even feature in
Python's data model.

From the point of view of a Python program, a reference *has no value*
(and no identity). It is just a metaphorical label, tag, or “sticky
note” one can invoke to make a specific object available.

> > That's significant, because unlike a mutable value you can never
> > again get at the old reference in the Python program.
>
> I don't understand what you mean by "can never again get at" it if you
> think you _can_ do it for mutable values.

In the above example, the different references originally created for
‘foo’ and ‘bar’ are inaccessible. ‘foo’ and ‘bar’ are not the same, they
are different references that happen to lead to the same object.

When ‘bar’ switches to a different reference, whatever reference it had
at prior points in time are gone for good. Any other references to the
same object continue on unaffected, because they are not the same
reference.



[0]: This axiom is unfortunately confused in the documentation's
  statement “you may think of it as the object’s address in memory”
  . That's not a
 

Re: Terminology: "reference" versus "pointer"

[Rustom Mody]

On Saturday, September 12, 2015 at 8:11:49 PM UTC+5:30, Laura Creighton wrote:
> In a message of Sat, 12 Sep 2015 05:46:35 -0700, Rustom Mody writes:
> >How about lay-English ontology in which "point to" and "refer to" are fairly
> >synonymous?
> 
> This I have found is important in teaching, which is why I favour 'bind'
> and 'binding' -- rather than pointer, pointer, refer to, referring.

Well we can play humpty dumpty and make any word mean whatever we like.
However if you are a teacher you will recognize a need for pictures.
And (as far as I can tell) "Random832" finds a need for the box-n-arrow
diagrams of classic data-structure books
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Laura Creighton]

In a message of Sat, 12 Sep 2015 05:46:35 -0700, Rustom Mody writes:
>How about lay-English ontology in which "point to" and "refer to" are fairly
>synonymous?

This I have found is important in teaching, which is why I favour 'bind'
and 'binding' -- rather than pointer, pointer, refer to, referring.

However, the problem that even people who have never used C, and
probably have never read about it, either (children) really want
a word that means 'when I use this name I get this physical chunk
of memory, over there' cannot be completely defeated with this
simple language change.  I know kids who think that python variable
names bind to actual physical chunks of their memory sticks, because
they haven't got around to understanding what RAM is, yet.

On the other hand, being able to say 'Right.  You are a garbage collector.
Because only garbage collectors need to care about such things.' makes for
a pretty memorable lesson.

Laura
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: "reference" versus "pointer"

[Rustom Mody]

On Saturday, September 12, 2015 at 11:57:01 AM UTC+5:30, Ben Finney wrote:
> Random832 writes:
> 
> > Ben Finney writes:
> > > The reference value is inaccessible to the program, it can only be
> > > used to get at the referenced object.
> >
> > What does it mean to access something, if not to do some operation on
> > it? Getting the referenced object is the operation you can do with it.
> 
> You've clearly committed to some ontology that just doesn't match the
> Python data model.

How about lay-English ontology in which "point to" and "refer to" are fairly
synonymous?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: “reference” versus “pointer”

[Random832]

Ben Finney  writes:
> With the significant difference that “pointer” implies that it has its
> own value accessible directly by the running program, such as a pointer
> in C.

Its own value *is* what you're accessing when you assign or return
it. You just can't do math on it, but there are lots of things you can't
do math on.

> That's different from a “reference”, which to my understanding implies
> the running program does *not* normally have direct access to it as a
> distinct value. The only way you can use a reference is to get at the
> object to which it refers.

In C++, references cannot be reassigned. I consider *that* the
fundamental difference - a pointer is a variable that you can reassign
and return; a reference always refers to the same object once created.

> That's the distinction I've been reying on for years, anyway: Python's
> names are references, collections are collections of references, etc.
> They aren't pointers because you can't get them as a distinct value; you
> can only use them to refer to the object at the other end.

Anyway, maybe we do need a term to distinguish Python/C#/Java pointers
from C/C++ pointers - maybe call it a "non-arithmetic" pointer, since
the key thing about it is you can't do pointer arithmetic on them to get
the object "next to" the one it points at.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: “reference” versus “pointer”

[Ben Finney]

Random832  writes:

> Ben Finney  writes:
> > With the significant difference that “pointer” implies that it has its
> > own value accessible directly by the running program, such as a pointer
> > in C.
>
> Its own value *is* what you're accessing when you assign or return it.

You're not describing Python references. But I don't know what you are
describing with all those “it”s — what language, what behaviour, what
concept?

Can you clarify what you mean, and what in my description you are
disagreeing with?

> > That's different from a “reference”, which to my understanding
> > implies the running program does *not* normally have direct access
> > to it as a distinct value. The only way you can use a reference is
> > to get at the object to which it refers.
>
> In C++, references cannot be reassigned. I consider *that* the
> fundamental difference - a pointer is a variable that you can reassign
> and return; a reference always refers to the same object once created.

Sure, that will work fine.

So in Python, we don't have pointers because we don't have access to
change or reassign them.

A Python reference isn't accessible and can't be changed; you can just
make another reference and switch to that.

You can't, for example, keep the old reference (there are no references
to references in Python), because they're not accessible as values in
themselves. Once you assign a different reference, the old one is gone
and can't be found again.

-- 
 \“[T]he great menace to progress is not ignorance but the |
  `\   illusion of knowledge.” —Daniel J. Boorstin, historian, |
_o__)1914–2004 |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: “reference” versus “pointer”

[Random832]

Ben Finney  writes:

> Random832  writes:
>
>> Ben Finney  writes:
>> > With the significant difference that “pointer” implies that it has its
>> > own value accessible directly by the running program, such as a pointer
>> > in C.
>>
>> Its own value *is* what you're accessing when you assign or return it.
>
> You're not describing Python references.

Yes I am. You're just making the implicit assumption that a "value" has
to be a number, and I was ignoring that assumption. The value is the
address of an object. Like I said, an arrow on a diagram.

> Can you clarify what you mean, and what in my description you are
> disagreeing with?
>
>> > That's different from a “reference”, which to my understanding
>> > implies the running program does *not* normally have direct access
>> > to it as a distinct value. The only way you can use a reference is
>> > to get at the object to which it refers.
>>
>> In C++, references cannot be reassigned. I consider *that* the
>> fundamental difference - a pointer is a variable that you can reassign
>> and return; a reference always refers to the same object once created.
>
> Sure, that will work fine.
>
> So in Python, we don't have pointers because we don't have access to
> change or reassign them.

Yes you do. That's _exactly what happens_ in an assignment statement -
you are reassigning it to the address of another object. And that's
something you *can't do* with references in C++.

Neither term is perfect, but "reference" is a *terrible* fit because of
that.

> A Python reference isn't accessible and can't be changed; you can just
> make another reference and switch to that.

Huh?

> You can't, for example, keep the old reference (there are no references
> to references in Python), because they're not accessible as values in
> themselves. Once you assign a different reference, the old one is gone
> and can't be found again.

You can keep it by copying it to somewhere. The pointer is the value,
not the variable, you don't _need_ a reference to it.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: “reference” versus “pointer”

[Ben Finney]

Random832  writes:

> Ben Finney  writes:
>
> > Random832  writes:
> >
> >> Ben Finney  writes:
> >> > With the significant difference that “pointer” implies that it has its
> >> > own value accessible directly by the running program, such as a pointer
> >> > in C.
> >>
> >> Its own value *is* what you're accessing when you assign or return it.
> >
> > You're not describing Python references.
>
> Yes I am. You're just making the implicit assumption that a "value" has
> to be a number, and I was ignoring that assumption. The value is the
> address of an object. Like I said, an arrow on a diagram.

I made no assumption about the type; I don't care how the reference is
implemented in the Python interpreter. That's not accessible to the
running Python program without some API.

My assertion still stands: the address of the object is *not* what the
reference is, in Python. Calling ‘id(foo)’ does not return a reference
to ‘foo’, so I don't know how you think the value is accessible in the
Python program.

The reference value is inaccessible to the program, it can only be used
to get at the referenced object.

> > So in Python, we don't have pointers because we don't have access to
> > change or reassign them.
>
> Yes you do. That's _exactly what happens_ in an assignment statement -
> you are reassigning it to the address of another object. And that's
> something you *can't do* with references in C++.

The operation you describe doesn't change the reference; it doesn't
mutate an existing value which can be compared with whatever value it
had before. Instead, it throws away one reference and replaces it with a
different one.

That's significant, because unlike a mutable value you can never again
get at the old reference in the Python program.

> > You can't, for example, keep the old reference (there are no references
> > to references in Python), because they're not accessible as values in
> > themselves. Once you assign a different reference, the old one is gone
> > and can't be found again.
>
> You can keep it by copying it to somewhere.

How do you propose to “copy” a reference in Python? Making a new
reference to the referenced object is not making a copy of the
reference.

-- 
 \ “Demagogue: One who preaches doctrines he knows to be untrue to |
  `\ men he knows to be idiots.” —Henry L. Mencken |
_o__)  |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Terminology: “reference” versus “pointer”

[Random832]

Ben Finney  writes:
> The reference value is inaccessible to the program, it can only be used
> to get at the referenced object.

That's like saying an integer is inaccessible since it can only be used
to add/subtract/etc (list of all operations you can do with an
integer). What does it mean to access something, if not to do some
operation on it? Getting the referenced object is the operation you can
do with it.

>> > So in Python, we don't have pointers because we don't have access to
>> > change or reassign them.
>>
>> Yes you do. That's _exactly what happens_ in an assignment statement -
>> you are reassigning it to the address of another object. And that's
>> something you *can't do* with references in C++.
>
> The operation you describe doesn't change the reference; it doesn't
> mutate an existing value which can be compared with whatever value it
> had before. Instead, it throws away one reference and replaces it with a
> different one.

So, if you have a list x, and assign a new value to x[0], it doesn't
change the list, because you can't compare the list to the value the
list had before?

You're not making any sense. It's a value. Changing it and "throwing
away and replacing with a different one" are the same thing.

> That's significant, because unlike a mutable value you can never again
> get at the old reference in the Python program.

I don't understand what you mean by "can never again get at" it if you
think you _can_ do it for mutable values.

>> > You can't, for example, keep the old reference (there are no references
>> > to references in Python), because they're not accessible as values in
>> > themselves. Once you assign a different reference, the old one is gone
>> > and can't be found again.
>>
>> You can keep it by copying it to somewhere.
>
> How do you propose to “copy” a reference in Python? Making a new
> reference to the referenced object is not making a copy of the
> reference.

Yes it is. I don't know why you think it's not, so I can't even figure
out how to respond to this.

-- 
https://mail.python.org/mailman/listinfo/python-list

Terminology: “reference” versus “pointer” (was: Python handles globals badly.)

[Ben Finney]

Random832  writes:

> Honestly, whether you want to call the thing a pointer or a reference,
> you have to call it *something*, and I think "reference" is a worse
> fit based on its connotations from C++. Whatever you call it, it's an
> arrow on a diagram.

With the significant difference that “pointer” implies that it has its
own value accessible directly by the running program, such as a pointer
in C.

That's different from a “reference”, which to my understanding implies
the running program does *not* normally have direct access to it as a
distinct value. The only way you can use a reference is to get at the
object to which it refers.

That's the distinction I've been reying on for years, anyway: Python's
names are references, collections are collections of references, etc.
They aren't pointers because you can't get them as a distinct value; you
can only use them to refer to the object at the other end.

-- 
 \ “If we don't believe in freedom of expression for people we |
  `\   despise, we don't believe in it at all.” —Noam Chomsky, |
_o__)   1992-11-25 |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list