Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #96368 > unrolled thread

Re: Python handles globals badly.

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Python handles globals badly. tdev@freenet.de - 2015-09-11 14:26 -0700
    Re: Python handles globals badly. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-11 23:50 +0200
      Re: Python handles globals badly. Michael Torrie <torriem@gmail.com> - 2015-09-11 18:01 -0600
        Re: Python handles globals badly. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-12 07:22 +0200
          Re: Python handles globals badly. MRAB <python@mrabarnett.plus.com> - 2015-09-12 18:05 +0100
            Re: Python handles globals badly. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-13 14:04 +0200
              Re: Python handles globals badly. Steven D'Aprano <steve@pearwood.info> - 2015-09-13 22:06 +1000
                Re: Python handles globals badly. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-13 14:11 +0200
                  Re: Python handles globals badly. Ned Batchelder <ned@nedbatchelder.com> - 2015-09-13 05:17 -0700
                    Re: Python handles globals badly. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-15 05:36 +0200
          Re: Python handles globals badly. Emile van Sebille <emile@fenx.com> - 2015-09-12 10:18 -0700
            Re: Python handles globals badly. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-13 14:06 +0200
              Re: Python handles globals badly. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-13 14:10 +0200
          Re: Python handles globals badly. Michael Torrie <torriem@gmail.com> - 2015-09-12 20:32 -0600
            Re: Python handles globals badly. "Skybuck Flying" <skybuck2000@hotmail.com> - 2015-09-13 14:05 +0200
      Re: Python handles globals badly. random832@fastmail.us - 2015-09-11 20:11 -0400
      Re: Python handles globals badly. Michael Torrie <torriem@gmail.com> - 2015-09-11 18:34 -0600
      Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-12 03:57 +0100
      Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-12 04:01 +0100
      Re: Python handles globals badly. Random832 <random832@fastmail.com> - 2015-09-12 00:06 -0400
      Re: Python handles globals badly. Random832 <random832@fastmail.com> - 2015-09-12 00:16 -0400
      Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-12 05:17 +0100
      Terminology: “reference” versus “pointer” (was: Python handles globals badly.) Ben Finney <ben+python@benfinney.id.au> - 2015-09-12 14:27 +1000
      Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-12 05:34 +0100
      Re: Python handles globals badly. Random832 <random832@fastmail.com> - 2015-09-12 00:34 -0400
      Re: Terminology: “reference” versus “pointer” Random832 <random832@fastmail.com> - 2015-09-12 00:42 -0400
        Re: Terminology: “reference” versus “pointer” Steven D'Aprano <steve@pearwood.info> - 2015-09-13 02:32 +1000
          Re: Terminology: "reference" versus "pointer" Rustom Mody <rustompmody@gmail.com> - 2015-09-12 09:54 -0700
            Re: Terminology: "reference" versus "pointer" Chris Angelico <rosuav@gmail.com> - 2015-09-13 03:06 +1000
            Re: Terminology: "reference" versus "pointer" Emile van Sebille <emile@fenx.com> - 2015-09-12 10:14 -0700
            Re: Terminology: "reference" versus "pointer" Steven D'Aprano <steve@pearwood.info> - 2015-09-13 03:24 +1000
              Re: Terminology: "reference" versus "pointer" Chris Angelico <rosuav@gmail.com> - 2015-09-13 03:34 +1000
      Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-12 05:45 +0100
      Re: Terminology: “reference” versus “pointer” Ben Finney <ben+python@benfinney.id.au> - 2015-09-12 14:52 +1000
      Re: Terminology: “reference” versus “pointer” Random832 <random832@fastmail.com> - 2015-09-12 01:03 -0400
        Re: Terminology: “reference” versus “pointer” Steven D'Aprano <steve@pearwood.info> - 2015-09-13 02:50 +1000
          Re: Terminology: "reference" versus "pointer" Rustom Mody <rustompmody@gmail.com> - 2015-09-12 10:04 -0700
      Re: Python handles globals badly. Random832 <random832@fastmail.com> - 2015-09-12 01:07 -0400
      Re: Terminology: “reference” versus “pointer” Ben Finney <ben+python@benfinney.id.au> - 2015-09-12 15:20 +1000
      Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-12 06:25 +0100
      Re: Python handles globals badly. Random832 <random832@fastmail.com> - 2015-09-12 01:35 -0400
      Re: Terminology: “reference” versus “pointer” Random832 <random832@fastmail.com> - 2015-09-12 01:42 -0400
      Re: Python handles globals badly. Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-12 06:54 +0100
      Re: Terminology: “reference” versus “pointer” Chris Angelico <rosuav@gmail.com> - 2015-09-12 16:02 +1000
      Re: Terminology: “reference” versus “pointer” Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-12 07:05 +0100
      Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-12 16:13 +1000
      Re: Terminology: “reference” versus “pointer” Random832 <random832@fastmail.com> - 2015-09-12 02:15 -0400
      Re: Python handles globals badly. Random832 <random832@fastmail.com> - 2015-09-12 02:25 -0400
      Re: Terminology: “reference” versus “pointer” Ben Finney <ben+python@benfinney.id.au> - 2015-09-12 16:26 +1000
        Re: Terminology: "reference" versus "pointer" Rustom Mody <rustompmody@gmail.com> - 2015-09-12 05:46 -0700
          Re: Terminology: "reference" versus "pointer" Laura Creighton <lac@openend.se> - 2015-09-12 16:41 +0200
            Re: Terminology: "reference" versus "pointer" Rustom Mody <rustompmody@gmail.com> - 2015-09-12 08:13 -0700
              Re: Terminology: "reference" versus "pointer" rurpy@yahoo.com - 2015-09-12 09:17 -0700
                Re: Terminology: "reference" versus "pointer" Rustom Mody <rustompmody@gmail.com> - 2015-09-12 10:12 -0700
                  Re: Terminology: "reference" versus "pointer" Steven D'Aprano <steve@pearwood.info> - 2015-09-13 04:14 +1000
                Re: Terminology: "reference" versus "pointer" Steven D'Aprano <steve@pearwood.info> - 2015-09-13 03:48 +1000
                  Re: Terminology: "reference" versus "pointer" rurpy@yahoo.com - 2015-09-12 11:45 -0700
                    Re: Terminology: "reference" versus "pointer" Steven D'Aprano <steve@pearwood.info> - 2015-09-13 22:50 +1000
                      Re: Terminology: "reference" versus "pointer" Steven D'Aprano <steve@pearwood.info> - 2015-09-13 23:29 +1000
                      Re: Terminology: "reference" versus "pointer" rurpy@yahoo.com - 2015-09-13 18:34 -0700
                        Re: Terminology: "reference" versus "pointer" Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-14 04:34 +0100
                  Re: Terminology: "reference" versus "pointer" rurpy@yahoo.com - 2015-09-12 12:58 -0700
                    Re: Terminology: "reference" versus "pointer" Emile van Sebille <emile@fenx.com> - 2015-09-12 15:14 -0700
                      Re: Terminology: "reference" versus "pointer" rurpy@yahoo.com - 2015-09-12 15:34 -0700
                        Re: Terminology: "reference" versus "pointer" Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-13 00:14 +0100
                          Re: Terminology: "reference" versus "pointer" Ned Batchelder <ned@nedbatchelder.com> - 2015-09-12 17:02 -0700
                            Re: Terminology: "reference" versus "pointer" Rustom Mody <rustompmody@gmail.com> - 2015-09-12 17:28 -0700
                            Re: Terminology: "reference" versus "pointer" rurpy@yahoo.com - 2015-09-12 17:44 -0700
                              Re: Terminology: "reference" versus "pointer" Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-09-13 03:22 +0100
                                Re: Terminology: "reference" versus "pointer" Ned Batchelder <ned@nedbatchelder.com> - 2015-09-12 19:25 -0700
                              Re: Terminology: "reference" versus "pointer" Michael Torrie <torriem@gmail.com> - 2015-09-12 20:35 -0600
                              Re: Terminology: "reference" versus "pointer" Ben Finney <ben+python@benfinney.id.au> - 2015-09-13 12:42 +1000
                                Re: Terminology: "reference" versus "pointer" rurpy@yahoo.com - 2015-09-13 08:31 -0700
                                  Re: Terminology: "reference" versus "pointer" Chris Angelico <rosuav@gmail.com> - 2015-09-14 01:39 +1000
                                  Re: Terminology: "reference" versus "pointer" Ben Finney <ben+python@benfinney.id.au> - 2015-09-14 06:48 +1000
                                    Re: Terminology: "reference" versus "pointer" rurpy@yahoo.com - 2015-09-13 18:13 -0700
                              Re: Terminology: "reference" versus "pointer" Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-09-13 12:32 -0400
                          Re: Terminology: "reference" versus "pointer" rurpy@yahoo.com - 2015-09-12 17:23 -0700
                        Re: Terminology: "reference" versus "pointer" Rustom Mody <rustompmody@gmail.com> - 2015-09-12 16:39 -0700
                          Re: Terminology: "reference" versus "pointer" Chris Angelico <rosuav@gmail.com> - 2015-09-13 10:19 +1000
                          Re: Terminology: "reference" versus "pointer" rurpy@yahoo.com - 2015-09-12 17:25 -0700
                            Re: Terminology: "reference" versus "pointer" rurpy@yahoo.com - 2015-09-12 18:07 -0700
              Re: Terminology: "reference" versus "pointer" Akira Li <4kir4.1i@gmail.com> - 2015-09-12 20:54 +0300
                Re: Terminology: "reference" versus "pointer" Rustom Mody <rustompmody@gmail.com> - 2015-09-12 11:21 -0700
                  Re: Terminology: "reference" versus "pointer" Jussi Piitulainen <harvesting@makes.email.invalid> - 2015-09-12 23:02 +0300
                    Re: Terminology: "reference" versus "pointer" Random832 <random832@fastmail.com> - 2015-09-12 17:10 -0400
                      Re: Terminology: "reference" versus "pointer" Steven D'Aprano <steve@pearwood.info> - 2015-09-13 12:30 +1000
                      Re: Terminology: "reference" versus "pointer" Jussi Piitulainen <harvesting@makes.email.invalid> - 2015-09-13 09:40 +0300
                  Re: Terminology: "reference" versus "pointer" Akira Li <4kir4.1i@gmail.com> - 2015-09-12 23:13 +0300
                  Re: Terminology: "reference" versus "pointer" Random832 <random832@fastmail.com> - 2015-09-12 17:27 -0400
                  Re: Terminology: "reference" versus "pointer" Akira Li <4kir4.1i@gmail.com> - 2015-09-13 21:04 +0300
                  Re: Terminology: "reference" versus "pointer" Chris Angelico <rosuav@gmail.com> - 2015-09-14 05:03 +1000
                  Re: Terminology: "reference" versus "pointer" Random832 <random832@fastmail.com> - 2015-09-13 15:04 -0400
                  Re: Terminology: "reference" versus "pointer" Akira Li <4kir4.1i@gmail.com> - 2015-09-14 02:17 +0300
                    Re: Terminology: "reference" versus "pointer" Steven D'Aprano <steve@pearwood.info> - 2015-09-14 11:10 +1000
                      Re: Terminology: "reference" versus "pointer" Akira Li <4kir4.1i@gmail.com> - 2015-09-14 04:22 +0300
                        Re: Terminology: "reference" versus "pointer" Steven D'Aprano <steve@pearwood.info> - 2015-09-14 12:38 +1000
                          Re: Terminology: "reference" versus "pointer" Akira Li <4kir4.1i@gmail.com> - 2015-09-14 06:23 +0300
                            Re: Terminology: "reference" versus "pointer" Steven D'Aprano <steve@pearwood.info> - 2015-09-15 02:59 +1000
                              Re: Terminology: "reference" versus "pointer" Akira Li <4kir4.1i@gmail.com> - 2015-09-14 20:24 +0300
                                Re: Terminology: "reference" versus "pointer" Ned Batchelder <ned@nedbatchelder.com> - 2015-09-14 11:29 -0700
                                  Re: Terminology: "reference" versus "pointer" Akira Li <4kir4.1i@gmail.com> - 2015-09-14 22:30 +0300
                                    Re: Terminology: "reference" versus "pointer" Ned Batchelder <ned@nedbatchelder.com> - 2015-09-14 13:16 -0700
                                      Re: Terminology: "reference" versus "pointer" Akira Li <4kir4.1i@gmail.com> - 2015-09-14 23:32 +0300
                      Re: Terminology: "reference" versus "pointer" Chris Angelico <rosuav@gmail.com> - 2015-09-14 11:30 +1000
                      Re: Terminology: "reference" versus "pointer" Akira Li <4kir4.1i@gmail.com> - 2015-09-14 05:26 +0300
                  Re: Terminology: "reference" versus "pointer" Chris Angelico <rosuav@gmail.com> - 2015-09-14 09:52 +1000
                  Re: Terminology: "reference" versus "pointer" Akira Li <4kir4.1i@gmail.com> - 2015-09-14 03:30 +0300
                  Re: Terminology: "reference" versus "pointer" Chris Angelico <rosuav@gmail.com> - 2015-09-14 10:58 +1000
                  Re: Terminology: "reference" versus "pointer" Random832 <random832@fastmail.com> - 2015-09-13 19:38 -0400
                  Re: Terminology: "reference" versus "pointer" Akira Li <4kir4.1i@gmail.com> - 2015-09-14 17:48 +0300
                  Re: Terminology: "reference" versus "pointer" Random832 <random832@fastmail.com> - 2015-09-14 11:10 -0400
                    Re: Terminology: "reference" versus "pointer" Steven D'Aprano <steve@pearwood.info> - 2015-09-15 03:03 +1000
                      Re: Terminology: "reference" versus "pointer" Random832 <random832@fastmail.com> - 2015-09-14 13:34 -0400
                        Re: Terminology: "reference" versus "pointer" Steven D'Aprano <steve@pearwood.info> - 2015-09-16 00:26 +1000
                      Re: Terminology: "reference" versus "pointer" Emile van Sebille <emile@fenx.com> - 2015-09-14 10:51 -0700
                        Re: Terminology: "reference" versus "pointer" Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-09-16 20:14 +1200
                          Re: Terminology: "reference" versus "pointer" Chris Angelico <rosuav@gmail.com> - 2015-09-16 18:18 +1000
                          Re: Terminology: "reference" versus "pointer" Ben Finney <ben+python@benfinney.id.au> - 2015-09-16 18:24 +1000
                          Re: Terminology: "reference" versus "pointer" Chris Angelico <rosuav@gmail.com> - 2015-09-16 18:33 +1000
                      Re: Terminology: "reference" versus "pointer" Chris Angelico <rosuav@gmail.com> - 2015-09-15 03:59 +1000
                      Re: Terminology: "reference" versus "pointer" Random832 <random832@fastmail.com> - 2015-09-14 14:02 -0400
                        Re: Terminology: "reference" versus "pointer" Steven D'Aprano <steve@pearwood.info> - 2015-09-16 00:14 +1000
                  Re: Terminology: "reference" versus "pointer" Akira Li <4kir4.1i@gmail.com> - 2015-09-14 20:45 +0300
                  Re: Terminology: "reference" versus "pointer" Random832 <random832@fastmail.com> - 2015-09-14 14:00 -0400
                  Re: Terminology: "reference" versus "pointer" Akira Li <4kir4.1i@gmail.com> - 2015-09-14 21:17 +0300
          Re: Terminology: "reference" versus "pointer" Steven D'Aprano <steve@pearwood.info> - 2015-09-13 03:08 +1000
            Re: Terminology: "reference" versus "pointer" Rustom Mody <rustompmody@gmail.com> - 2015-09-12 10:26 -0700
          Re: Terminology: "reference" versus "pointer" Ben Finney <ben+python@benfinney.id.au> - 2015-09-13 11:13 +1000
      Re: Python handles globals badly. Chris Angelico <rosuav@gmail.com> - 2015-09-12 16:27 +1000
      Re: Terminology: “reference” versus “pointer” Chris Angelico <rosuav@gmail.com> - 2015-09-12 16:31 +1000
    Re: Python handles globals badly. Ian Kelly <ian.g.kelly@gmail.com> - 2015-09-11 16:10 -0600
    Re: Python handles globals badly. MRAB <python@mrabarnett.plus.com> - 2015-09-12 00:03 +0100

Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7  Next page →

#96405

Mark Lawrence <breamoreboy@yahoo.co.uk> writes:
> Let's put it another way, in the 15 years I've been using Python I do
> not recall any experienced Python programmer using "pointer", so what
> makes you think, in 2015, that you are correct and everybody else is
> wrong?  I still say that everything in Python is an object, and should
> add that it has one or more things, "names", that are associated with
> it.  Hence my preferred analogy about the sticky note.

So is player3[3] also a name, a sticky note? What if we copy player3 to
another name; does it get two sticky notes, player3[3] and foo[3]? Your
"sticky note" analogy doesn't unify variables/names/whatever you want to
call them with other places that you can assign stuff to, and it implies
that the objects themselves have knowledge of their "names", and that
names are global (if I have two functions each with a result variable,
does that mean there are two different result sticky notes?)

It doesn't matter that a pointer isn't what it's *called*, it's what it
*is*. And it's not an object, because you can copy it to more than one
place with only one object.

[toc] | [prev] | [next] | [standalone]

#96407 — Re: Terminology: “reference” versus “pointer”

Ben Finney <ben+python@benfinney.id.au> 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.

[toc] | [prev] | [next] | [standalone]

#96408

On 12/09/2015 06:35, Random832 wrote:
> Mark Lawrence <breamoreboy@yahoo.co.uk> writes:
>> Let's put it another way, in the 15 years I've been using Python I do
>> not recall any experienced Python programmer using "pointer", so what
>> makes you think, in 2015, that you are correct and everybody else is
>> wrong?  I still say that everything in Python is an object, and should
>> add that it has one or more things, "names", that are associated with
>> it.  Hence my preferred analogy about the sticky note.
>
> So is player3[3] also a name, a sticky note? What if we copy player3 to
> another name; does it get two sticky notes, player3[3] and foo[3]? Your
> "sticky note" analogy doesn't unify variables/names/whatever you want to
> call them with other places that you can assign stuff to, and it implies
> that the objects themselves have knowledge of their "names", and that
> names are global (if I have two functions each with a result variable,
> does that mean there are two different result sticky notes?)
>
> It doesn't matter that a pointer isn't what it's *called*, it's what it
> *is*. And it's not an object, because you can copy it to more than one
> place with only one object.
>

There is NO CONCEPT in Python of a "pointer".  player3[3] is the fourth 
item of a list or similar, or a reference to something in a dictionary, 
but regardless of the type it is an object that has a name player3. 
player3 then gets copied to foo.  Both names are referring to the same 
object.  It certainly DOES NOT imply anything about objects having 
knowledge of their names and it DOES NOT say anything about the scope of 
names.  As for "two functions each with a result variable" I haven't the 
faintest notion what you could be talking about, would you please 
explain for the benefit of everybody reading this thread.

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

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#96409 — Re: Terminology: “reference” versus “pointer”

On Sat, Sep 12, 2015 at 3:03 PM, Random832 <random832@fastmail.com> 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

[toc] | [prev] | [next] | [standalone]

#96410 — Re: Terminology: “reference” versus “pointer”

On 12/09/2015 06:42, Random832 wrote:
> Ben Finney <ben+python@benfinney.id.au> 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

[toc] | [prev] | [next] | [standalone]

#96411

On Sat, Sep 12, 2015 at 3:35 PM, Random832 <random832@fastmail.com> wrote:
> Mark Lawrence <breamoreboy@yahoo.co.uk> writes:
>> Let's put it another way, in the 15 years I've been using Python I do
>> not recall any experienced Python programmer using "pointer", so what
>> makes you think, in 2015, that you are correct and everybody else is
>> wrong?  I still say that everything in Python is an object, and should
>> add that it has one or more things, "names", that are associated with
>> it.  Hence my preferred analogy about the sticky note.
>
> So is player3[3] also a name, a sticky note? What if we copy player3 to
> another name; does it get two sticky notes, player3[3] and foo[3]? Your
> "sticky note" analogy doesn't unify variables/names/whatever you want to
> call them with other places that you can assign stuff to, and it implies
> that the objects themselves have knowledge of their "names", and that
> names are global (if I have two functions each with a result variable,
> does that mean there are two different result sticky notes?)

Whatever you want to use to describe a name-binding reference, the
exact same thing applies to a list element or anything else. If your
analogy is strings tied to sheets of paper, with sticky notes on the
ends of strings to represent actual names, then you have similar
strings connecting list elements to their referents. (The sticky notes
aren't actually part of the objects, and you just have to understand
that you can't trace a string "backwards", only "forwards"; there's no
way to start with an object and ask "what refers to this?".)

Here. Ned Batchelder explains it better than I can.

http://nedbatchelder.com/text/names1.html
https://www.youtube.com/watch?v=_AEJHKGk9ns

ChrisA

[toc] | [prev] | [next] | [standalone]

#96412 — Re: Terminology: “reference” versus “pointer”

Mark Lawrence <breamoreboy@yahoo.co.uk> 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.

[toc] | [prev] | [next] | [standalone]

#96413

Chris Angelico <rosuav@gmail.com> writes:
> Here. Ned Batchelder explains it better than I can.

See, those diagrams are perfect (well, almost, I think the names should
have square boxes too). They're arrows. They *point* at
things. *Pointers*.

The boxes are variables. The circles represent special boxes
(implemented in C or Java or whatever) that hold things other than
pointers and therefore can't be used as Python variables.

[toc] | [prev] | [next] | [standalone]

#96414 — Re: Terminology: “reference” versus “pointer”

Random832 <random832@fastmail.com> writes:

> Ben Finney <ben+python@benfinney.id.au> 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”
  <URL:https://docs.python.org/3/reference/datamodel.html>. That's not a
  guarantee of the data model, it is merely meant to help the reader
  understand the concept.

  Note that the documentation deliberately does *not* say the identity
  is the object's address in memory except as a note about the
  *implementation* in CPython. That is not part of the data model.

-- 
 \          “It is well to remember that the entire universe, with one |
  `\   trifling exception, is composed of others.” —John Andrew Holmes |
_o__)                                                                  |
Ben Finney

[toc] | [prev] | [next] | [standalone]

#96421 — Re: Terminology: "reference" versus "pointer"

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?

[toc] | [prev] | [next] | [standalone]

#96422 — Re: Terminology: "reference" versus "pointer"

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

[toc] | [prev] | [next] | [standalone]

#96423 — Re: Terminology: "reference" versus "pointer"

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

[toc] | [prev] | [next] | [standalone]

#96425 — Re: Terminology: "reference" versus "pointer"

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. 

[toc] | [prev] | [next] | [standalone]

#96436 — Re: Terminology: "reference" versus "pointer"

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

[toc] | [prev] | [next] | [standalone]

#96444 — Re: Terminology: "reference" versus "pointer"

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

[toc] | [prev] | [next] | [standalone]

#96442 — Re: Terminology: "reference" versus "pointer"

On Sun, 13 Sep 2015 02:17 am, rurpy@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

[toc] | [prev] | [next] | [standalone]

#96447 — Re: Terminology: "reference" versus "pointer"

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.)

[toc] | [prev] | [next] | [standalone]

#96500 — Re: Terminology: "reference" versus "pointer"

On Sun, 13 Sep 2015 04:45 am, rurpy@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

[toc] | [prev] | [next] | [standalone]

#96501 — Re: Terminology: "reference" versus "pointer"

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

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


> But as I said to Rurpy, 

Er, that would be you.

Editing fail. Sorry about that.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#96544 — Re: Terminology: "reference" versus "pointer"

On 09/13/2015 06:50 AM, Steven D'Aprano wrote:
> On Sun, 13 Sep 2015 04:45 am, rurpy@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 snippet, despite their superficial syntactical similarity.
C has allows one to mention values both directly and via pointers
(or references if you prefer) and Python only the latter. You chose
your C example to be an example of the kind of access Python doesn't
do, so of course I would not call x in the C example a pointer or
reference. /char *s = "foo";/ and /s = "foo"/ would have been a 
more analogous comparison. But continuing with your example...

In C, x is immutably bound to the "object" containing 23. The object
is an unboxed int at some fixed memory location and by immutably bound
I mean that x will always refer to that memory location. You cannot
change that binding, all you can do is change the contents of the
object to some other int value.

In Python of course all that is not true. As you well know, you
can reassign x and when you do you don't change the contents of the
object x was pointing to (or referencing if you insist) -- you change
x itself. The object known as 23 is still sitting there, pretty as
you please, waiting to be accessed though some other name, or some
other unnamed pointer (or reference if you insist) or garbage
collected or for the program to end. Meanwhile, x is there, now
(dare I say it?) pointing to some other object, maybe an int(24),
which it sitting in memory somewhere. We know it has an existence
independent of x by many ways which you already know and I need not
repeat.

So what then is x in Python? Well of course it's a name in the
source code. But how does it exist in the running program? Where
is it and what does it contain? Python does not tell us but we know
that whatever and wherever it is, when we mentioned it before we got
back (the object) 23 and now when we mention it we get back (the
object) 24. It *behaves* as though it were a pointer (or reference
if you prefer).

a = [23]

What is a[0]? This time the Python docs tell us explicitly:

"Some objects contain *references* to other objects; these are
called containers" [Language Ref 3.1: Objects, values and types]

The thing in a[0] is a *reference* (or sloppily, a pointer).

b = 24
a[0] = 24

You say assignment in the first case assigns 24 directly to b and
the Python docs tell us that assignment in the second case assigns
a reference (to 24) when the assignment is done to a container.

That's an utterly needless distinction. A simpler, more consistent
description is to say Python assigns a reference (in this case to
the object representing 24) to the thing on the left side of the
"=".  Always. There is nothing implementation dependent about this.

It is more than possible to do this, it is advantageous because now
it is obvious that named things work the same way unnamed things do
(ie in python everything is an object and all objects are accessed
through references -- emphasizing the consistency and simplicity of
python's object model.)

Of course it is also necessary to also have a concomitant rule that
when a name is mentioned it is automatically dereferenced. That is
not unique to Python; in Go the only thing you can do with pointers
is dereference them.

> 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.

It is not outside the language abstraction if the description is
"as-if" equivalent to every possible implementation choice, that
is, it is isomorphic. (Probably not the right word but you get
the idea).

This discussion has bifurcated into two related but distinct issues:
1) Whether pointer is acceptable terminology for reference.
2) What in Python should or should not be described in terms
of reference/pointer.
There were some places above where I wasn't sure if your objection
was on the grounds of 1 or 2.

[toc] | [prev] | [next] | [standalone]

Page 3 of 7 — ← Prev page 1 2 [3] 4 5 6 7  Next page →

Back to top | Article view | comp.lang.python

csiph-web