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

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

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

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

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

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

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

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

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

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

Rustom Mody <rustompmody@gmail.com> writes:

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

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

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

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

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

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

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

And some people see no advantage to playing semantics and proclaiming
"The arrows in C look similar to the arrows in python but they are not the same"

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

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

Rustom Mody writes:

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

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

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

Works for me.

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

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

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

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

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

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

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

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

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

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


Colour coding:

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

Shapes:

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

IDs:

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

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

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


Astral travel:

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

Hatch marks:

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

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

----|----||----|||----/----//----\----\\----X----XX---->----<----

That is, reading from left to right:

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


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



-- 
Steven

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

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

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

I prefer to outline my code as code, with comments where needed, without
irrelevant details. Those pointers and tags are usually irrelevant, best
omitted altogether.

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

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

Rustom Mody <rustompmody@gmail.com> writes:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Random832 <random832@fastmail.com> writes:

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

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

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

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

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

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

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

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

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

Or consider this collections of all Unicode characters:

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

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

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

Or this:

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

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

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


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

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

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

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

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

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

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

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

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

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

ChrisA

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

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

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

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

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

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

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

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

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

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

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

Random832 <random832@fastmail.com> writes:

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

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

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

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

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

If you mean this quote from [1]:

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

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

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

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

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

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

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

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

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

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

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

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

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


Please explain.

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



-- 
Steven

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

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

Steven D'Aprano <steve@pearwood.info> writes:

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

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

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

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

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

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


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



-- 
Steven

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

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

Steven D'Aprano <steve@pearwood.info> writes:

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

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

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

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

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

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

Thanks. You mean this example?

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


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


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

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

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



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

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



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



-- 
Steven

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

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

Steven D'Aprano <steve@pearwood.info> writes:

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

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


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

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

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

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

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

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

csiph-web