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 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7  Next page →

#96390

Mark Lawrence <breamoreboy@yahoo.co.uk> writes:
> My favourite analogy for Python names, the sticky note, here
> https://mail.python.org/pipermail/tutor/2006-October/049767.html

Is player3[3] also a sticky note? Wouldn't the note have to have the id
of player3 written on it somehow? Should the player3 sticky note have
the id of the global namespace that "player3" is valid in written on it?

I like my analogy better because it means both player3 and (the list we
call player3)[3] are both the *same* kind of thing: boxes that have
pointers in them (i.e. variables).

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

#96392

On 12/09/2015 05:06, Random832 wrote:
> Mark Lawrence <breamoreboy@yahoo.co.uk> writes:
>
>> On 12/09/2015 01:11, random832@fastmail.us wrote:
>> If everything in Python is an object, how can it assign a pointer?
>> Especially how do Jython and IronPython assign pointers?
>
> The Java and .NET runtimes also have pointers, they just don't [usually]
> call them pointers, just like Python doesn't call them pointers (a match
> made in... well, somewhere starting with an H, for sure).
>
> 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.
>

I think pointer is even worse because of its connection with C and hence 
cPython.  What is wrong with object if that is the only thing Python 
knows about?

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

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

Random832 <random832@fastmail.com> 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

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

#96394

On 12/09/2015 05:16, Random832 wrote:
> Mark Lawrence <breamoreboy@yahoo.co.uk> writes:
>> My favourite analogy for Python names, the sticky note, here
>> https://mail.python.org/pipermail/tutor/2006-October/049767.html
>
> Is player3[3] also a sticky note? Wouldn't the note have to have the id
> of player3 written on it somehow? Should the player3 sticky note have
> the id of the global namespace that "player3" is valid in written on it?
>
> I like my analogy better because it means both player3 and (the list we
> call player3)[3] are both the *same* kind of thing: boxes that have
> pointers in them (i.e. variables).
>

For the final time I hope, "pointer" is not appropriate for Python, so 
I'll stick with the sticky note analogy, thanks all the same.

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

#96395

Mark Lawrence <breamoreboy@yahoo.co.uk> writes:
> I think pointer is even worse because of its connection with C and
> hence cPython.  What is wrong with object if that is the only thing
> Python knows about?

Because the object is the *thing the arrow points at*. You don't have
two objects when store the same object in two variables (names, list
slots, whatever), but you do have two pointers.

And they *are* pointers in cPython - so that "connection" is a feature,
not a bug.

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

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

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

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

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

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

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

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

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

<snip>

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

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

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

On Sun, Sep 13, 2015 at 2:54 AM, Rustom Mody <rustompmody@gmail.com> 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

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

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

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

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

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

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

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

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

On Sun, Sep 13, 2015 at 3:24 AM, Steven D'Aprano <steve@pearwood.info> 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.

</troll>

ChrisA

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

#96398

On 12/09/2015 05:34, Random832 wrote:
> Mark Lawrence <breamoreboy@yahoo.co.uk> writes:
>> I think pointer is even worse because of its connection with C and
>> hence cPython.  What is wrong with object if that is the only thing
>> Python knows about?
>
> Because the object is the *thing the arrow points at*. You don't have
> two objects when store the same object in two variables (names, list
> slots, whatever), but you do have two pointers.
>
> And they *are* pointers in cPython - so that "connection" is a feature,
> not a bug.
>

How do I access these pointers?  Is there a builtin called pointer() 
that's analogous to id()?  I'll ask again, where do pointers come into 
the Jython and IronPython models?  How do I access their pointers, the 
same builtin?  The fact that the underlying implementation language has 
some terminology that it uses, has no bearing on the actual language 
being implemented.  This seems to me rather important, or have I missed 
something here?

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

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

Random832 <random832@fastmail.com> writes:

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

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

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

Ben Finney <ben+python@benfinney.id.au> writes:

> Random832 <random832@fastmail.com> writes:
>
>> Ben Finney <ben+python@benfinney.id.au> 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.

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

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

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

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

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

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?

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

#96401

Mark Lawrence <breamoreboy@yahoo.co.uk> writes:
> How do I access these pointers?  Is there a builtin called pointer()
> that's analogous to id()?

You access them *all the time*. They are the *only* thing you access.

But if you want... pointer = lambda x: return x

> I'll ask again, where do pointers come into
> the Jython and IronPython models?  How do I access their pointers, the
> same builtin?  The fact that the underlying implementation language
> has some terminology that it uses, has no bearing on the actual
> language being implemented.

I am not using "pointer" as language-specific terminology, I am using it
as *the* name of the concept we are talking about. The Java and .NET
runtimes *don't* use that terminology, but they still *actually* have
pointers, in the same way that Python does.

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

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

Random832 <random832@fastmail.com> writes:

> Ben Finney <ben+python@benfinney.id.au> writes:
>
> > Random832 <random832@fastmail.com> writes:
> >
> >> Ben Finney <ben+python@benfinney.id.au> 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

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

#96404

On 12/09/2015 06:07, Random832 wrote:
> Mark Lawrence <breamoreboy@yahoo.co.uk> writes:
>> How do I access these pointers?  Is there a builtin called pointer()
>> that's analogous to id()?
>
> You access them *all the time*. They are the *only* thing you access.
>
> But if you want... pointer = lambda x: return x
>
>> I'll ask again, where do pointers come into
>> the Jython and IronPython models?  How do I access their pointers, the
>> same builtin?  The fact that the underlying implementation language
>> has some terminology that it uses, has no bearing on the actual
>> language being implemented.
>
> I am not using "pointer" as language-specific terminology, I am using it
> as *the* name of the concept we are talking about. The Java and .NET
> runtimes *don't* use that terminology, but they still *actually* have
> pointers, in the same way that Python does.
>

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.

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

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

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

csiph-web