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

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

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

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

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

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

--Ned.

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

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

Ned Batchelder <ned@nedbatchelder.com> writes:
...
> What do you feel is missing from Steven's diagram?

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

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

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

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

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

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

--Ned.

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

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

Ned Batchelder <ned@nedbatchelder.com> writes:

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

I don't understand what you are talking about.

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

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

On Mon, Sep 14, 2015 at 11:22 AM, Akira Li <4kir4.1i@gmail.com> 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

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

ChrisA

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

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

Chris Angelico <rosuav@gmail.com> writes:

> On Mon, Sep 14, 2015 at 11:22 AM, Akira Li <4kir4.1i@gmail.com> 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
>
> Still not sure what the problem is. As per Python's object model, the
> lists contain references to range objects. a contains two references
> to the same range object, b contains references to each of two
> distinct range objects. What of it?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ChrisA

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

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

Chris Angelico <rosuav@gmail.com> writes:

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

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

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

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

lists are _mutable_ in Python.

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

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

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

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

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

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

ChrisA

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


-- 
Steven

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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


What's wrong with this?

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




-- 
Steven

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

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

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

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

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

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

Emile

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

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

Emile van Sebille wrote:

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

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

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

-- 
Greg

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

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

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

Quantum computing is the way of the future!

ChrisA

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

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

Chris Angelico <rosuav@gmail.com> writes:

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

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

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

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

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

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

What do we want?

Guido's time machine!!

When do we want it?

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

ChrisA

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

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

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

csiph-web