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

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

I'm wrong or Will we fix the ducks limp?

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

Contents

  I'm wrong or Will we fix the ducks limp? Sayth Renshaw <flebber.crue@gmail.com> - 2016-06-03 07:20 -0700
    Re: I'm wrong or Will we fix the ducks limp? Paul Rudin <paul.nospam@rudin.co.uk> - 2016-06-03 15:34 +0100
      Re: I'm wrong or Will we fix the ducks limp? Sayth Renshaw <flebber.crue@gmail.com> - 2016-06-03 08:04 -0700
        Re: I'm wrong or Will we fix the ducks limp? Ian Kelly <ian.g.kelly@gmail.com> - 2016-06-03 09:35 -0600
          Re: I'm wrong or Will we fix the ducks limp? Sayth Renshaw <flebber.crue@gmail.com> - 2016-06-03 08:50 -0700
            Re: I'm wrong or Will we fix the ducks limp? Michael Selik <michael.selik@gmail.com> - 2016-06-03 16:04 +0000
              Re: I'm wrong or Will we fix the ducks limp? Sayth Renshaw <flebber.crue@gmail.com> - 2016-06-03 16:06 -0700
                Re: I'm wrong or Will we fix the ducks limp? Steven D'Aprano <steve@pearwood.info> - 2016-06-04 12:31 +1000
                  Re: I'm wrong or Will we fix the ducks limp? Christopher Reimer <christopher_reimer@icloud.com> - 2016-06-03 19:50 -0700
                    Re: I'm wrong or Will we fix the ducks limp? Steven D'Aprano <steve@pearwood.info> - 2016-06-04 19:12 +1000
        Re: I'm wrong or Will we fix the ducks limp? Matt Wheeler <m@funkyhat.org> - 2016-06-03 15:54 +0000
          Re: I'm wrong or Will we fix the ducks limp? Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-04 20:17 -0700
            Re: I'm wrong or Will we fix the ducks limp? Steven D'Aprano <steve@pearwood.info> - 2016-06-05 16:37 +1000
              Re: I'm wrong or Will we fix the ducks limp? Marko Rauhamaa <marko@pacujo.net> - 2016-06-05 11:01 +0300
                Re: I'm wrong or Will we fix the ducks limp? Random832 <random832@fastmail.com> - 2016-06-05 13:53 -0400
                  Re: I'm wrong or Will we fix the ducks limp? Marko Rauhamaa <marko@pacujo.net> - 2016-06-05 22:20 +0300
                    Re: I'm wrong or Will we fix the ducks limp? Random832 <random832@fastmail.com> - 2016-06-05 17:16 -0400
                      Re: I'm wrong or Will we fix the ducks limp? Marko Rauhamaa <marko@pacujo.net> - 2016-06-06 11:13 +0300
                  Re: I'm wrong or Will we fix the ducks limp? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-06 13:08 +1200
                    Re: I'm wrong or Will we fix the ducks limp? Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-05 18:28 -0700
              Re: I'm wrong or Will we fix the ducks limp? Random832 <random832@fastmail.com> - 2016-06-05 13:42 -0400
                Re: I'm wrong or Will we fix the ducks limp? Marko Rauhamaa <marko@pacujo.net> - 2016-06-05 22:38 +0300
                Re: I'm wrong or Will we fix the ducks limp? Steven D'Aprano <steve@pearwood.info> - 2016-06-06 13:52 +1000
                  Re: I'm wrong or Will we fix the ducks limp? Random832 <random832@fastmail.com> - 2016-06-06 00:08 -0400
                    Re: I'm wrong or Will we fix the ducks limp? Steven D'Aprano <steve@pearwood.info> - 2016-06-07 01:42 +1000
                      Re: I'm wrong or Will we fix the ducks limp? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-07 17:42 +1200
                        Re: I'm wrong or Will we fix the ducks limp? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-06-07 20:18 +1000
                          Re: I'm wrong or Will we fix the ducks limp? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-07 14:32 +0200
                            Re: I'm wrong or Will we fix the ducks limp? Steven D'Aprano <steve@pearwood.info> - 2016-06-08 02:03 +1000
                              Re: I'm wrong or Will we fix the ducks limp? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-08 10:08 +0200
                          Re: I'm wrong or Will we fix the ducks limp? Random832 <random832@fastmail.com> - 2016-06-07 11:33 -0400
                          Re: I'm wrong or Will we fix the ducks limp? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-08 09:53 +0200
                            Re: I'm wrong or Will we fix the ducks limp? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-06-08 18:47 +1000
                              Re: I'm wrong or Will we fix the ducks limp? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-08 11:41 +0200
                                Re: I'm wrong or Will we fix the ducks limp? BartC <bc@freeuk.com> - 2016-06-08 11:33 +0100
                                  Re: I'm wrong or Will we fix the ducks limp? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-08 13:01 +0200
                                    Re: I'm wrong or Will we fix the ducks limp? BartC <bc@freeuk.com> - 2016-06-08 13:34 +0100
                                      Re: I'm wrong or Will we fix the ducks limp? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-08 16:18 +0200
                                        Re: I'm wrong or Will we fix the ducks limp? Marko Rauhamaa <marko@pacujo.net> - 2016-06-08 19:37 +0300
                                          Re: I'm wrong or Will we fix the ducks limp? Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-08 19:49 -0700
                                          Re: I'm wrong or Will we fix the ducks limp? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-09 09:30 +0200
                                            Re: I'm wrong or Will we fix the ducks limp? Marko Rauhamaa <marko@pacujo.net> - 2016-06-09 12:19 +0300
                                              Re: I'm wrong or Will we fix the ducks limp? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-09 12:19 +0200
                                                Re: I'm wrong or Will we fix the ducks limp? Marko Rauhamaa <marko@pacujo.net> - 2016-06-09 16:13 +0300
                                            Re: I'm wrong or Will we fix the ducks limp? lists@juliensalort.org (Julien Salort) - 2016-06-09 13:46 +0200
                                              Re: I'm wrong or Will we fix the ducks limp? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-09 14:35 +0200
                                          Re: I'm wrong or Will we fix the ducks limp? Paul Rudin <paul.nospam@rudin.co.uk> - 2016-06-09 11:00 +0100
                                            Re: I'm wrong or Will we fix the ducks limp? Marko Rauhamaa <marko@pacujo.net> - 2016-06-09 15:56 +0300
                                              Re: I'm wrong or Will we fix the ducks limp? Paul Rudin <paul.nospam@rudin.co.uk> - 2016-06-09 15:09 +0100
                                                Re: I'm wrong or Will we fix the ducks limp? Marko Rauhamaa <marko@pacujo.net> - 2016-06-09 18:14 +0300
                                                  Re: I'm wrong or Will we fix the ducks limp? Paul Rudin <paul.nospam@rudin.co.uk> - 2016-06-09 17:22 +0100
                                                    Re: I'm wrong or Will we fix the ducks limp? Paul Rudin <paul.nospam@rudin.co.uk> - 2016-06-09 17:48 +0100
                                                    Re: I'm wrong or Will we fix the ducks limp? Marko Rauhamaa <marko@pacujo.net> - 2016-06-09 22:35 +0300
                                                  Re: I'm wrong or Will we fix the ducks limp? Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-06-10 08:31 +0300
                                          Re: I'm wrong or Will we fix the ducks limp? Random832 <random832@fastmail.com> - 2016-06-09 14:36 -0400
                                        Re: I'm wrong or Will we fix the ducks limp? BartC <bc@freeuk.com> - 2016-06-08 18:29 +0100
                                          Re: I'm wrong or Will we fix the ducks limp? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-09 09:50 +0200
                                            Re: I'm wrong or Will we fix the ducks limp? BartC <bc@freeuk.com> - 2016-06-09 10:10 +0100
                                              Re: I'm wrong or Will we fix the ducks limp? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-09 11:55 +0200
                                                Re: I'm wrong or Will we fix the ducks limp? BartC <bc@freeuk.com> - 2016-06-09 11:48 +0100
                                                  Re: I'm wrong or Will we fix the ducks limp? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-09 13:08 +0200
                                                    Re: I'm wrong or Will we fix the ducks limp? BartC <bc@freeuk.com> - 2016-06-09 13:25 +0100
                                                      Re: I'm wrong or Will we fix the ducks limp? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-09 14:48 +0200
                                    Re: I'm wrong or Will we fix the ducks limp? Rustom Mody <rustompmody@gmail.com> - 2016-06-08 05:36 -0700
                                Re: I'm wrong or Will we fix the ducks limp? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2016-06-09 17:36 +1000
                                  Re: I'm wrong or Will we fix the ducks limp? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-09 11:46 +0200
                                    Re: I'm wrong or Will we fix the ducks limp? Marko Rauhamaa <marko@pacujo.net> - 2016-06-09 13:03 +0300
                                      Re: I'm wrong or Will we fix the ducks limp? BartC <bc@freeuk.com> - 2016-06-09 11:42 +0100
                                    Re: I'm wrong or Will we fix the ducks limp? BartC <bc@freeuk.com> - 2016-06-09 11:53 +0100
                                      Re: I'm wrong or Will we fix the ducks limp? Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-06-09 13:56 +0300
                                      Re: I'm wrong or Will we fix the ducks limp? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-09 13:19 +0200
                                        Re: I'm wrong or Will we fix the ducks limp? BartC <bc@freeuk.com> - 2016-06-09 13:17 +0100
                                          Re: I'm wrong or Will we fix the ducks limp? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-09 14:59 +0200
                  Re: I'm wrong or Will we fix the ducks limp? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-06 18:37 +1200
                    Re: I'm wrong or Will we fix the ducks limp? Steven D'Aprano <steve@pearwood.info> - 2016-06-07 02:19 +1000
                      Re: I'm wrong or Will we fix the ducks limp? Random832 <random832@fastmail.com> - 2016-06-06 12:57 -0400
                        Re: I'm wrong or Will we fix the ducks limp? Steven D'Aprano <steve@pearwood.info> - 2016-06-07 04:59 +1000
                          Re: I'm wrong or Will we fix the ducks limp? Random832 <random832@fastmail.com> - 2016-06-06 17:13 -0400
                            Re: I'm wrong or Will we fix the ducks limp? Marko Rauhamaa <marko@pacujo.net> - 2016-06-07 00:47 +0300
                              Re: I'm wrong or Will we fix the ducks limp? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-07 19:03 +1200
                                Re: I'm wrong or Will we fix the ducks limp? Marko Rauhamaa <marko@pacujo.net> - 2016-06-07 10:56 +0300
                                  Re: I'm wrong or Will we fix the ducks limp? Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-06-07 11:41 +0300
                                  Re: I'm wrong or Will we fix the ducks limp? BartC <bc@freeuk.com> - 2016-06-07 11:49 +0100
                                Re: I'm wrong or Will we fix the ducks limp? Random832 <random832@fastmail.com> - 2016-06-07 11:14 -0400
                                  Re: I'm wrong or Will we fix the ducks limp? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-08 17:59 +1200
                          Re: I'm wrong or Will we fix the ducks limp? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-07 18:33 +1200
                            Re: I'm wrong or Will we fix the ducks limp? Chris Angelico <rosuav@gmail.com> - 2016-06-07 16:55 +1000
                      Re: I'm wrong or Will we fix the ducks limp? BartC <bc@freeuk.com> - 2016-06-06 22:55 +0100
                      Re: I'm wrong or Will we fix the ducks limp? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-06-07 18:20 +1200
                  Re: I'm wrong or Will we fix the ducks limp? Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-06-06 11:23 +0200
                    Re: I'm wrong or Will we fix the ducks limp? Marko Rauhamaa <marko@pacujo.net> - 2016-06-06 13:10 +0300
                  Re: I'm wrong or Will we fix the ducks limp? Chris Angelico <rosuav@gmail.com> - 2016-06-06 21:57 +1000
              Re: I'm wrong or Will we fix the ducks limp? BartC <bc@freeuk.com> - 2016-06-06 13:35 +0100
            Re: I'm wrong or Will we fix the ducks limp? Lawrence D’Oliveiro <lawrencedo99@gmail.com> - 2016-06-05 18:25 -0700
    Re: I'm wrong or Will we fix the ducks limp? Peter Pearson <pkpearson@nowhere.invalid> - 2016-06-03 16:05 +0000
      Re: I'm wrong or Will we fix the ducks limp? Sayth Renshaw <flebber.crue@gmail.com> - 2016-06-03 16:09 -0700
        Re: I'm wrong or Will we fix the ducks limp? cs@zip.com.au - 2016-06-06 08:41 +1000
    Re: I'm wrong or Will we fix the ducks limp? Nagy László Zsolt <gandalf@shopzeus.com> - 2016-06-03 18:11 +0200
      Re: I'm wrong or Will we fix the ducks limp? Sayth Renshaw <flebber.crue@gmail.com> - 2016-06-03 16:11 -0700
    Re: I'm wrong or Will we fix the ducks limp? Terry Reedy <tjreedy@udel.edu> - 2016-06-03 22:12 -0400
    Re: I'm wrong or Will we fix the ducks limp? jfine2358@gmail.com - 2016-06-06 07:32 -0700

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

#109730

Op 09-06-16 om 12:48 schreef BartC:
>
> What does it matter?
>
> If swap() can be implemented via such a function, then it means that
> the language has such capability, which can be useful in different
> scenarios.
>
> If it can't, then the language hasn't.
>
> Python doesn't have it so it can't implement swap like that.
>
> There's no need to bring references into it at all.

Whether a language can implement a swap procedure like that is
not the same question as whether the language variables are
references or not.

Since the topic was whether or not python has reference variables,
is seems there is no need to bring this swap procedure into it at all,
instead of turning it around and pretending it was about the
swap procedure.

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

#109734

On 09/06/2016 12:08, Antoon Pardon wrote:
> Op 09-06-16 om 12:48 schreef BartC:
>>
>> What does it matter?
>>
>> If swap() can be implemented via such a function, then it means that
>> the language has such capability, which can be useful in different
>> scenarios.
>>
>> If it can't, then the language hasn't.
>>
>> Python doesn't have it so it can't implement swap like that.
>>
>> There's no need to bring references into it at all.
>
> Whether a language can implement a swap procedure like that is
> not the same question as whether the language variables are
> references or not.

Now /you're/ turning it around.

I'm not interested in the internal references that Python currently 
uses. (I've called them /object references/.)

I'm talking about a different kind of reference, possible /name 
references/, they would make possible new things ....

> Since the topic was whether or not python has reference variables,
> is seems there is no need to bring this swap procedure into it at all,
> instead of turning it around and pretending it was about the
> swap procedure.

... such as implementing a function that can exchange the values of its 
caller's two arguments.

In bytecode, Python might need to swap variables using:

    load a
    load b
    store a
    store b

(which can get inefficient if swapping a[i+j-1] and b[j-i+1]). A name 
reference would allow:

    loadref a
    loadref b
    swap

-- 
Bartc

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

#109738

Op 09-06-16 om 14:25 schreef BartC:
> On 09/06/2016 12:08, Antoon Pardon wrote:
>> Op 09-06-16 om 12:48 schreef BartC:
>>>
>>> What does it matter?
>>>
>>> If swap() can be implemented via such a function, then it means that
>>> the language has such capability, which can be useful in different
>>> scenarios.
>>>
>>> If it can't, then the language hasn't.
>>>
>>> Python doesn't have it so it can't implement swap like that.
>>>
>>> There's no need to bring references into it at all.
>>
>> Whether a language can implement a swap procedure like that is
>> not the same question as whether the language variables are
>> references or not.
>
> Now /you're/ turning it around.
>
> I'm not interested in the internal references that Python currently
> uses. (I've called them /object references/.)
>
> I'm talking about a different kind of reference, possible /name
> references/, they would make possible new things ....

That you talk about something different, doesn't make others
wrong when they use the label "reference" for what they are
talking about.

If someone writes that variables in python are references or
reference variables, then there is an historical meaning for
the label "reference" that makes this statement true.

Protesting the statment because you think of something different
when you read "reference", just means you didn't understand
the original statement.

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

#109674

On Wednesday, June 8, 2016 at 4:32:33 PM UTC+5:30, Antoon Pardon wrote:

> It means that if you mutate the object through one variable,
> you can see the result of that mutation through the other variable. But if the
> assignment doesn't mutate, you can't have such effect through assignment.
> 

Its called aliasing:
https://en.wikipedia.org/wiki/Aliasing_%28computing%29
And is the principal reason why we need to talk in terms of pointer/references/box-n-arrows
etc

> In python, you can sometimes simulate a mutating assignment and then we get this.
> 
>     >>> A = [8, 5, 3, 2]
>     >>> B = A
>     >>> B[:] = [3, 5, 8, 13]
>     >>> A
>     [3, 5, 8, 13]

Neat example -- thanks -- something for my tomorrow class
More telling than the one I usually use to talk of this stuff which runs thus:

>>> a=[[1,2,],[1,2]]
>>> a
[[1, 2], [1, 2]]
>>> inner=[1,2]
>>> b=[inner,inner]
>>> b
[[1, 2], [1, 2]]
# So a and b look the same


>>> a == b
True
# So even python thinks them the same

# But Uh... oh... 
>>> a[0][0]=3
>>> a
[[3, 2], [1, 2]]
>>> b[0][0]=3
>>> b
[[3, 2], [3, 2]]
# They dont behave the same!

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

#109704

On Wednesday 08 June 2016 19:41, Antoon Pardon wrote:

>> What you seem to be describing is similar to reference parameter semantics
>> from Pascal. Assignment doesn't work that way in C, or Python.
> 
> I disagree. In python the assignment does work similar to the reference
> parameter semantics in pascal. See the following
> 
>   A = range[4]
>   B = A
>   B[2] = 5
>   print A # [0, 1, 5, 2]
> 
> This is exactly the result you would get with B as a reference parameter in
> pascal.

It might be the same result, but it is a different cause.

Your example demonstrates object mutation, not assignment. Although Python uses 
the same syntax X = X for both name binding (assignment) and item assignment, 
item assignment is a *mutator method*: it calls B.__setitem__, which modifies B 
in place. Since the name A is bound to the same object, it is hardly surprising 
that A shows the same change.

But since you think that assignment in Python behaves like Pascal var 
parameters (reference variables), you should be able to write a "swap" 
procedure that swaps two arguments. That's the definitive test for reference 
parameters, since it works in all languages with reference parameters (e.g. 
Pascal, Basic and C++), and doesn't work in any language without them (or 
equivalent, like Algol's pass-by-name parameters).

The Pythonic way to swap two variables is to use tuple unpacking:

a, b = b, a

but that uses a completely different mechanism to get the same effect. 
"Reference parameter" is all about mechanism.

I want to see the Python equivalent of Pascal's var parameters:

procedure swap(var a:integer; var b:integer);
  var
    temp: integer;
  begin
    temp := a;
    a := b;
    b := a;
  end;

(or the Algol equivalent, a slightly different mechanism), and then see it 
called like this:

a = 1
b = 2
swap(a, b)  # absolutely NOT `a, b = swap(a, b)`
assert a == 2 and b == 1


without passing in or making use of hard-coded parameter names.

That is my challenge to you: if you can write such a function, in pure Python, 
which swaps two parameters given as ordinary arguments (passing their names as 
strings does not count), then I will cheerfully apologise for doubting you, 
admit that I was wrong, and publicly acknowledge that Python does have 
reference variables just like you said.

If you cannot meet that challenge, then I would like you to acknowledge that 
whatever Python variables are, and however Python's assignment works, it is 
*not* the same as Pascal's reference variables, and so calling Python variables 
"reference variables" is misleading and an abuse of a well-established term 
from computer science since long before Python even existed.

Are you willing to accept that challenge?

Or are you going to try to weasel out of it by changing the definition of 
reference parameter to mean "whatever I want it to mean to avoid admitting I 
was wrong"?


>> And of course Python doesn't have reference variables either. There is
>> nothing you can do in Python to get this effect:
>>
>> a = 1
>> b = a
>> b = 99
>> assert a == 99
> 
> It is true that you can't get such an effect in python, but that doesn't
> imply that python doesn't have reference variables (as an abstract notion).
> Because having reference variables doesn't imply you can have that effect.

Ah, well that answers that question. Weasel out it is.



-- 
Steve

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

#109717

Op 09-06-16 om 09:36 schreef Steven D'Aprano:
> On Wednesday 08 June 2016 19:41, Antoon Pardon wrote:
>
>>> What you seem to be describing is similar to reference parameter semantics
>>> from Pascal. Assignment doesn't work that way in C, or Python.
>> I disagree. In python the assignment does work similar to the reference
>> parameter semantics in pascal. See the following
>>
>>   A = range[4]
>>   B = A
>>   B[2] = 5
>>   print A # [0, 1, 5, 2]
>>
>> This is exactly the result you would get with B as a reference parameter in
>> pascal.
> It might be the same result, but it is a different cause.
>
> Your example demonstrates object mutation, not assignment.

Generally assignment and mutation don't contradict each other.
So IMO the cause is the same, a mutation. In some languages you
can mutate your variable through an assignment and in others you
can't.

>  But since you think that assignment in Python behaves like Pascal var 
> parameters (reference variables), you should be able to write a "swap" 
> procedure that swaps two arguments. That's the definitive test for reference 
> parameters, since it works in all languages with reference parameters (e.g. 
> Pascal, Basic and C++), and doesn't work in any language without them (or 
> equivalent, like Algol's pass-by-name parameters).

It works in those languages because their the assignment mutates the variable
that is assigned to. It is the fact that one can mutate a variable through an
alias that makes it a reference variable, that is how it was already used in
smalltalk. So because in python assignments don't mutate, you can't write
a "swap" procedure in python, but AFAIR neither could you in smalltalk.

You are confusing what it is that makes something a reference, with how
an assignment can have an effect on a reference. It makes no sense to
expect you can do the same with reference assignments as you can do
with mutating assignments.


> That is my challenge to you: if you can write such a function, in pure Python, 
> which swaps two parameters given as ordinary arguments (passing their names as 
> strings does not count), then I will cheerfully apologise for doubting you, 
> admit that I was wrong, and publicly acknowledge that Python does have 
> reference variables just like you said.
>
> If you cannot meet that challenge, then I would like you to acknowledge that 
> whatever Python variables are, and however Python's assignment works, it is 
> *not* the same as Pascal's reference variables, and so calling Python variables 
> "reference variables" is misleading and an abuse of a well-established term 
> from computer science since long before Python even existed.

Your challenge, shows that you don't fully understand what reference variables
are. The behaviour you see in Pascal, doesn't depend (alone) on the parameter
being a reference parameter. It also depends on the fact that the assignment
in pascal mutates the variable that is assigned to. Variables are references
if they are aliases, so that if you mutate through one alias, the mutation is
visible through other aliases. So your challenge comes down to expecting me
to mutate something by means that in python don't allow mutation.

> Are you willing to accept that challenge?
>
> Or are you going to try to weasel out of it by changing the definition of 
> reference parameter to mean "whatever I want it to mean to avoid admitting I 
> was wrong"?

I am using reference as it was already use by smalltalk.

>
>> It is true that you can't get such an effect in python, but that doesn't
>> imply that python doesn't have reference variables (as an abstract notion).
>> Because having reference variables doesn't imply you can have that effect.
> Ah, well that answers that question. Weasel out it is.

That is presuming you have the right understanding.

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

#109721

Antoon Pardon <antoon.pardon@rece.vub.ac.be>:

> Your challenge, shows that you don't fully understand what reference
> variables are. The behaviour you see in Pascal, doesn't depend (alone)
> on the parameter being a reference parameter. It also depends on the
> fact that the assignment in pascal mutates the variable that is
> assigned to. Variables are references if they are aliases, so that if
> you mutate through one alias, the mutation is visible through other
> aliases. So your challenge comes down to expecting me to mutate
> something by means that in python don't allow mutation.

I think bringing Pascal in this discussion is only confusing matters.

Let me repeat the abstract Python data model I gave a couple of days
back:

   - there are labeled *pegs* ("variables")

   - there are *puppies* ("objects")

   - each peg has one *leash* hanging from it

   - each leash is tied to a puppy

   - each puppy can have zero one or more leashes tied to it

   - some puppies can hold leashes in their *mouths*

   - some puppies can take hold of new leashes and let go of leashes

I'm not joking. Everybody is arguing about preconceived notions tied to
terminology. The peg-leash-puppy model is accurate and extensive.

We can now give semantics to Python's execution model. For example,

   - every rvalue expression evaluates to a leash

   - the lvalue expression identifies a peg or a mouth

   - the assignment statement hangs a leash on a peg or in a mouth


Marko

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

#109725

On 09/06/2016 11:03, Marko Rauhamaa wrote:
> Antoon Pardon <antoon.pardon@rece.vub.ac.be>:
>
>> Your challenge, shows that you don't fully understand what reference
>> variables are. The behaviour you see in Pascal, doesn't depend (alone)
>> on the parameter being a reference parameter. It also depends on the
>> fact that the assignment in pascal mutates the variable that is
>> assigned to. Variables are references if they are aliases, so that if
>> you mutate through one alias, the mutation is visible through other
>> aliases. So your challenge comes down to expecting me to mutate
>> something by means that in python don't allow mutation.
>
> I think bringing Pascal in this discussion is only confusing matters.
>
> Let me repeat the abstract Python data model I gave a couple of days
> back:
>
>    - there are labeled *pegs* ("variables")
>
>    - there are *puppies* ("objects")
>
>    - each peg has one *leash* hanging from it
>
>    - each leash is tied to a puppy
>
>    - each puppy can have zero one or more leashes tied to it
>
>    - some puppies can hold leashes in their *mouths*
>
>    - some puppies can take hold of new leashes and let go of leashes
>
> I'm not joking. Everybody is arguing about preconceived notions tied to
> terminology. The peg-leash-puppy model is accurate and extensive.
>
> We can now give semantics to Python's execution model. For example,
>
>    - every rvalue expression evaluates to a leash
>
>    - the lvalue expression identifies a peg or a mouth
>
>    - the assignment statement hangs a leash on a peg or in a mouth

And to implement swap() you need a leash that can be tied to a peg.

(Here, I'm assuming 'hanging from' and 'tied to' suggest that a leash is 
uni-directional. But it's possible to imagine that a different part of a 
peg is used to hang an out-going leash, compared to tying an incoming 
one. Just like the puppies have necks to tie incoming leashes  to (via 
collars to avoid cruelty) and mouths for out-going ones.)

-- 
Bartc

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

#109727

On 09/06/2016 10:46, Antoon Pardon wrote:
> Op 09-06-16 om 09:36 schreef Steven D'Aprano:

>> Your example demonstrates object mutation, not assignment.
>
> Generally assignment and mutation don't contradict each other.
> So IMO the cause is the same, a mutation. In some languages you
> can mutate your variable through an assignment and in others you
> can't.

I think this is what is confusing you.

Mutation is like repairing or customising my car.

Full assignment is like buying a new car.

The two are very different, even though they might involve the same "=" 
operator.

Python object references work like the registration (license) plate on a 
car. Whatever you do via that, it will be the same car.

Full references require the address of the house.

-- 
Bartc

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

#109729

BartC writes:

> On 09/06/2016 10:46, Antoon Pardon wrote:
>> Op 09-06-16 om 09:36 schreef Steven D'Aprano:
>
>>> Your example demonstrates object mutation, not assignment.
>>
>> Generally assignment and mutation don't contradict each other.
>> So IMO the cause is the same, a mutation. In some languages you
>> can mutate your variable through an assignment and in others you
>> can't.
>
> I think this is what is confusing you.
>
> Mutation is like repairing or customising my car.
>
> Full assignment is like buying a new car.

Nice.

[- -]

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

#109731

Op 09-06-16 om 12:53 schreef BartC:
> On 09/06/2016 10:46, Antoon Pardon wrote:
>> Op 09-06-16 om 09:36 schreef Steven D'Aprano:
>
>>> Your example demonstrates object mutation, not assignment.
>>
>> Generally assignment and mutation don't contradict each other.
>> So IMO the cause is the same, a mutation. In some languages you
>> can mutate your variable through an assignment and in others you
>> can't.
>
> I think this is what is confusing you.
>
> Mutation is like repairing or customising my car.
>
> Full assignment is like buying a new car.

I think you are confused. Full assignment of C struct or
Pascal record is the same as mutating all individual
attributes. You don't get a new record/instance as in
Python. You replace the value of the attributes with
something else.

As far a language semantics are concerned, you get the
(new) car at scope entry, all assigments later are
mutations.

You may think of assignment as like buying a new car,
that is not how the semantics of languages like pascal
and C are defined.

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

#109733

On 09/06/2016 12:19, Antoon Pardon wrote:
> Op 09-06-16 om 12:53 schreef BartC:
>> On 09/06/2016 10:46, Antoon Pardon wrote:
>>> Op 09-06-16 om 09:36 schreef Steven D'Aprano:
>>
>>>> Your example demonstrates object mutation, not assignment.
>>>
>>> Generally assignment and mutation don't contradict each other.
>>> So IMO the cause is the same, a mutation. In some languages you
>>> can mutate your variable through an assignment and in others you
>>> can't.
>>
>> I think this is what is confusing you.
>>
>> Mutation is like repairing or customising my car.
>>
>> Full assignment is like buying a new car.
>
> I think you are confused. Full assignment of C struct or
> Pascal record is the same as mutating all individual
> attributes. You don't get a new record/instance as in
> Python. You replace the value of the attributes with
> something else.
>
> As far a language semantics are concerned, you get the
> (new) car at scope entry, all assigments later are
> mutations.
>
> You may think of assignment as like buying a new car,
> that is not how the semantics of languages like pascal
> and C are defined.

Static languages like C and Pascal don't make for a good comparison. C 
is just too low level: anything is possible so can be twisted any way. A 
bit like assembly.

C variables have a fixed type, which you can't change by assignment (so 
a Ford can't change to a different marque). But being low-level, 
assignment in C is just copying N bytes from A to B. Which is also what 
happens when, instead of copying a whole struct, you mutate all of it by 
assigning the fields one by one.

Python assignments are bit more sophisticated, and there are real 
differences between full assignment (where a variable ends up with a 
different object reference) and mutation (where it might be the same, 
but modified, object).

-- 
Bartc

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

#109742

Op 09-06-16 om 14:17 schreef BartC:
> On 09/06/2016 12:19, Antoon Pardon wrote:
>> Op 09-06-16 om 12:53 schreef BartC:
>>> On 09/06/2016 10:46, Antoon Pardon wrote:
>>>> Op 09-06-16 om 09:36 schreef Steven D'Aprano:
>>>
>>>>> Your example demonstrates object mutation, not assignment.
>>>>
>>>> Generally assignment and mutation don't contradict each other.
>>>> So IMO the cause is the same, a mutation. In some languages you
>>>> can mutate your variable through an assignment and in others you
>>>> can't.
>>>
>>> I think this is what is confusing you.
>>>
>>> Mutation is like repairing or customising my car.
>>>
>>> Full assignment is like buying a new car.
>>
>> I think you are confused. Full assignment of C struct or
>> Pascal record is the same as mutating all individual
>> attributes. You don't get a new record/instance as in
>> Python. You replace the value of the attributes with
>> something else.
>>
>> As far a language semantics are concerned, you get the
>> (new) car at scope entry, all assigments later are
>> mutations.
>>
>> You may think of assignment as like buying a new car,
>> that is not how the semantics of languages like pascal
>> and C are defined.
>
> Static languages like C and Pascal don't make for a good comparison. C
> is just too low level: anything is possible so can be twisted any way.
> A bit like assembly.

But this "low" level is needed to make a swap work.

>
> C variables have a fixed type, which you can't change by assignment
> (so a Ford can't change to a different marque). But being low-level,
> assignment in C is just copying N bytes from A to B. Which is also
> what happens when, instead of copying a whole struct, you mutate all
> of it by assigning the fields one by one.

Exactly and it is this mutating that makes a swap
procedure possible in the languages that come up
here.

>
> Python assignments are bit more sophisticated, and there are real
> differences between full assignment (where a variable ends up with a
> different object reference) and mutation (where it might be the same,
> but modified, object).

Yes and it is this difference that makes it impossible
to write a swap procedure, despite the variables in python
being reference variables.

Make up what ever kind of reference you wil. If your assignment
will only change references and won't mutate, you will not be
able to write a swap procedure.

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

#109542

Steven D'Aprano wrote:
> The *name* "x" is an entity which is bound to (i.e. a reference to) the
> object 99, in some specific namespace, at some specific time. The name
> itself is an English word consisting of a single letter, "x".

This is one reason why the term "name" is not good subsitute
for the term "variable". The string "x" is not the same thing
as the variable x, a fact that's obscured if you call the
variable a "name".

A better analogy along the presidential line would be the
name "President of the United States". That name can refer
to different people at different times, so there must be
some piece of state in the world that records the association
between the character string "President of the United States"
and the person who currently holds that office.

It's that piece of state that the OP is calling a "box".
I don't know what form it actually takes, probably an
official piece of paper somewhere, which may well be
kept in a box. But the box doesn't contain Barack Obama
himself, it only contains something that refers to him.

-- 
Greg

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

#109578

On Mon, 6 Jun 2016 04:37 pm, Gregory Ewing wrote:

> Steven D'Aprano wrote:
>> The *name* "x" is an entity which is bound to (i.e. a reference to) the
>> object 99, in some specific namespace, at some specific time. The name
>> itself is an English word consisting of a single letter, "x".
> 
> This is one reason why the term "name" is not good subsitute
> for the term "variable". The string "x" is not the same thing
> as the variable x, a fact that's obscured if you call the
> variable a "name".

I never said that the string "x" is the same thing as the variable x. I made
it clear, well I thought it was clear, that the *implementation* of names
in CPython uses string keys in dictionaries, but that's not what a name is.
A name is just a abstract, human-readable label. We prefer meaningful names
like "x" or "number_of_pages", but an interpreter could use 64-bit
cryptographic hashes or UUIDs or whatever it likes.

(A Python interpreter would have to find some way to map those UUIDs back to
human readable strings, so that we can call vars() or globals() or
equivalent and see the names we expect. But another language need not do
that.)


> A better analogy along the presidential line would be the
> name "President of the United States". That name can refer
> to different people at different times, so there must be
> some piece of state in the world that records the association
> between the character string "President of the United States"
> and the person who currently holds that office.

How ironic, after telling me off for saying that variables were strings
(which I didn't do), you're now talking about the POTUS being a "character
string".

You are right that there must be some piece of state that associates the
label "POTUS" or "Barack Obama" with the man. That's the essential feature
of a name binding. In human languages, we generally use words for labels.
(Sometimes we use numbers, as in "Prisoner 23848".) But we also need to
distinguish between talking about the POTUS and talking about the
*label* "POTUS", and the usual way of doing that in English is as I just
did, but putting it in quotation marks, or referring to it as "the word
POTUS", or some other equivalent phrase.


> It's that piece of state that the OP is calling a "box".
> I don't know what form it actually takes, probably an
> official piece of paper somewhere, which may well be
> kept in a box. But the box doesn't contain Barack Obama
> himself, it only contains something that refers to him.

Yes. And? 

Two points:

(1) When we refer to Barack Obama, we're not referring to his birth
certificate, and when we refer to the POTUS, we're not referring to this
hypothetical box where the official piece of paper resides. We're referring
to the man. Just as when we refer to the x in "x = 999", we mean 999, not
some analogue to a birth certificate or certificate of being president.

(2) The "variables are like boxes" metaphor applies to static languages like
C and Pascal, where the compiler has knowledge of what variables will
exist. Such languages allocate space for the variables at compile time,
usually using fixed memory locations on the stack, or in registers, but
rarely dynamically in the heap. That's exactly what Python doesn't do.



-- 
Steven

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

#109582

On Mon, Jun 6, 2016, at 12:19, Steven D'Aprano wrote:
> (2) The "variables are like boxes" metaphor applies to static languages
> like
> C and Pascal, where the compiler has knowledge of what variables will
> exist. Such languages allocate space for the variables at compile time,
> usually using fixed memory locations on the stack, or in registers, but
> rarely dynamically in the heap.

As you're so fond of pointing out, those are implementation details. And
CPython does it too (using frame objects rather than the stack, but the
relevant point here is that it *does* have knowledge of what variables
will exist), for local variables.

> That's exactly what Python doesn't do.

And anyway, the fact that the "boxes" are dynamically allocated rather
than "fixed memory locations on the stack"* doesn't stop them from being
boxes (if you prefer Marko's analogy, "Some puppies hold leashes in
their mouths"). Attributes and list items and dictionary keys and values
are also boxes.

*isn't the whole point of it being a stack that they're not fixed? I
assume you meant fixed offsets from the stack frame.

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

#109589

On Tue, 7 Jun 2016 02:57 am, Random832 wrote:

> On Mon, Jun 6, 2016, at 12:19, Steven D'Aprano wrote:
>> (2) The "variables are like boxes" metaphor applies to static languages
>> like
>> C and Pascal, where the compiler has knowledge of what variables will
>> exist. Such languages allocate space for the variables at compile time,
>> usually using fixed memory locations on the stack, or in registers, but
>> rarely dynamically in the heap.
> 
> As you're so fond of pointing out, those are implementation details. 

I believe that both C and Pascal specify that they are statically declared
languages with a variable model broadly as I have described it above,
the "box" model.

There may be implementation-dependent details I've glossed over (I don't
know the entire Pascal and C specifications by heart), but I think I'm on
fairly solid ground to say that a language that is just like C except that
it allocates variables in a hash table at runtime, using runtime lookups
for variable access, would not satisfy the C89 or C99 standards.

In any case, the point is that there are behavioural differences between a
static "box" model and a dynamic "name binding" mode for variables. Python
uses the later, not the former. You couldn't implement Python with a
strictly static box model, since you have to support `exec`.


> And 
> CPython does it too (using frame objects rather than the stack, but the
> relevant point here is that it *does* have knowledge of what variables
> will exist), for local variables.

A very good point, however that *is* an implementation detail: Jython and
IronPython don't have that limitation, as CPython does, and so their
locals() is a proper namespace. But even in CPython 2, you can create local
variables dynamically:


py> def test():
...     exec("x = 1")
...     print(x)
...
py> test()
1


Though that doesn't work in Python 3.


>> That's exactly what Python doesn't do.
> 
> And anyway, the fact that the "boxes" are dynamically allocated rather
> than "fixed memory locations on the stack"* doesn't stop them from being
> boxes 

"Variables as boxes" is a long-standing, well-known metaphor for the C and
Pascal variable model, one where the value is copied into the box
(metaphorically), or to be more precise, where variables have fixed
locations and on assignment values are copied to that location. Python is
not like that, and using the same metaphor for two completely different
models is a sure way to get obfuscation and confusion rather than
understanding.

Weren't you the one who just a few days ago complained about Python folks
unilaterally redefining established terms in contradiction of how those
terms are used by the rest of the programming community?

The broader programming community understands "variables as boxes" to mean
fixed size boxes in fixed locations with assignment-as-copying, as used by
C and Pascal. I don't think it is helpful for you to invent your own
metaphor of Python-style variables being boxes.


> (if you prefer Marko's analogy, "Some puppies hold leashes in 
> their mouths").

I don't know what Marko's analogy is. Puppies with leashes? What?


> Attributes and list items and dictionary keys and values 
> are also boxes.

They're not boxes in the sense of the "variables are boxes" model. I don't
know what other sense you intend the metaphor to be understood.


> *isn't the whole point of it being a stack that they're not fixed? I
> assume you meant fixed offsets from the stack frame.

Yes, thank you for the correction. (That's not sarcasm.)




-- 
Steven

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

#109593

On Mon, Jun 6, 2016, at 14:59, Steven D'Aprano wrote:
> "Variables as boxes" is a long-standing, well-known metaphor for the C
> and
> Pascal variable model, one where the value is copied into the box
> (metaphorically), or to be more precise, where variables have fixed
> locations and on assignment values are copied to that location.

I don't think that's "to be more precise" at all. I think that is an
entirely different model.

The box metaphor as I understand it involves a lot of boxes, which may
contain arrows (call them pointers, references, or whatever) emerging
from them pointing to other boxes, which are all free-floating with no
implication that any of them are fixed locations or are not dynamically
allocated.

The most classic use of it, after all, is for Lisp, in which two boxes
glued together represent a cons cell, something absolutely nobody would
accuse of having a fixed location. Google "lisp box diagram"  for any
number of examples.

What does a diagram of *your* "variables as boxes" model look like?

> The broader programming community

Between this and the argument about "constructor" terminology, clearly
you and I see "the broader programming community" very differently.

> understands "variables as boxes" to mean fixed size boxes in fixed
> locations with assignment-as-copying, as used by C and Pascal. I don't
> think it is helpful for you to invent your own metaphor of Python-
> style variables being boxes.

> > (if you prefer Marko's analogy, "Some puppies hold leashes in 
> > their mouths").
> 
> I don't know what Marko's analogy is. Puppies with leashes? What?

It was a couple days ago in this thread, in a reply to a post by you.

On Sun, Jun 5, 2016, at 04:01, Marko Rauhamaa wrote:
M> You could also think of variables as pegs, references as leashes, and
M> objects as cute puppies. One puppy could be held with multiple
leashes
M> hung on separate pegs. Some puppies hold leashes in their mouths.
Every
M> leash is tied to a puppy or a special wooden post called None.

(I disagreed with him on "None" needing to be a special wooden post for
the analogy to work)

R> > Attributes and list items and dictionary keys and values 
R> > are also boxes.
S> 
S> They're not boxes in the sense of the "variables are boxes" model.

I would say 'yes they are', but clearly *your* "broader programming
community's" version of the ""variables are boxes" model" is different
from everyone else's. I don't think continuing this discussion is likely
to be productive.

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

#109594

Random832 <random832@fastmail.com>:

> The box metaphor as I understand it involves a lot of boxes, which may
> contain arrows (call them pointers, references, or whatever) emerging
> from them pointing to other boxes, which are all free-floating with no
> implication that any of them are fixed locations or are not
> dynamically allocated.

When I first studied Java, I quickly made a realization that

   Java's    .  (dot)

is

   C's       -> (arrow)

That's all there was to it. You could replace Java with Python.

Where a C programmer would write:

   x->y->z

a Python programmer would express the same as:

   x.y.z

> The most classic use of it, after all, is for Lisp, in which two boxes
> glued together represent a cons cell, something absolutely nobody
> would accuse of having a fixed location. Google "lisp box diagram" for
> any number of examples.

There doesn't seem to be any way to introduce Lisp/Java/Python's data
model except through lower-level programming concepts.

> On Sun, Jun 5, 2016, at 04:01, Marko Rauhamaa wrote:
> M> You could also think of variables as pegs, references as leashes,
> M> and objects as cute puppies. One puppy could be held with multiple
> M> leashes hung on separate pegs. Some puppies hold leashes in their
> M> mouths. Every leash is tied to a puppy or a special wooden post
> M> called None.
>
> (I disagreed with him on "None" needing to be a special wooden post for
> the analogy to work)

That's not an analogy -- that's an abstract data model!

Note: no boxes! However, there are strings attached. Now you can truly
*bind* objects to variables.

Seriously, though, it is notable that the high-level programming
languages pretty unanimously refuse to make variables first-class
objects. I wonder why.

Python (et al) can closely emulate pointers to variables with arrays:

   >>> def double_it(it):
   ...     it[0] *= 2
   ... 
   >>> it = [7]
   >>> double_it(it)
   >>> it[0]
   14
   >>> double_it(it)
   >>> it[0]
   28

although that would be bad style in Python, which can return tuples.


Marko

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

#109608

Marko Rauhamaa wrote:
 > [concerning leashed puppies]
> Note: no boxes! However, there are strings attached. Now you can truly
> *bind* objects to variables.

If you wanted to really bind them good and proper,
you'd use duct tape (or "duck tape" as some people
call it -- arguably more appropriate in this context!)

> Seriously, though, it is notable that the high-level programming
> languages pretty unanimously refuse to make variables first-class
> objects. I wonder why.

That's an interesting question. One reason might be
that in the absence of static type analysis, assigning
to a variable holding a reference to another variable
would be ambiguous. For example, suppose Python had
an & operator that gives you an object referring to
a variable somehow. Then, after

a = 42
b = 17
c = &a
c = &b

does 'c' now hold a reference to the variable 'b', or
does it still hold a reference to 'a' and 'a' now
holds a reference to 'b'?

Somehow these two operations would have to be spelled
different ways, which means you would need to know
whether you were dealing with a variable reference or
not. So they wouldn't really be first-class, in the
sense of being treated on an equal footing with
ordinary variables.

-- 
Greg

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

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

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

csiph-web