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

#109703

Op 08-06-16 om 18:37 schreef Marko Rauhamaa:
> Antoon Pardon <antoon.pardon@rece.vub.ac.be>:
>
>> You can do something like that in simula, but only because
>> simula has two kinds of assignments. One kind that is
>> simular to python and one that is similar to C.
>> The one that is similar that python is the reference assignment.
> I see Python as doing the exact same thing with variables as C.
>
> What is different is that in Python, every expression evaluates to a
> pointer. Thus, you can only assign pointers to variables.

Then you think wrong. Python has no pointers, that is an implementation
detail.

In python when you have two variables, and you assign one to the other
you then have two variables that share an object.

In C when you have two variables and you assign one to the other you
then have two variable each refering to their own object that are copies
of each other. 

And yes that sharing of variables in python can be simulated by copying
pointers in C. Maybe the simularities between variables in python can be
made isomorphic with a specific subset of pointer operations in C.

The fact is that such an isomorphism would be limited to specific
pointer operations and would not extend to how variable generally
behave in C.

In a rather straight forward environment with classes/structs that
have an x and y attribute, the following lines behave differently
in C and Python.

  A.x = 1;
  A.y = 2;

  B = A;

  B.x = 3;
  B.y = 4;


In C the variable A will still be x:1, y:2.
In Python the variable A will be x:3, y:4. 

So no, Python doesn't do the exact same thing with variables as C.

-- 
Antoon Pardon.

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

#109715

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

> Op 08-06-16 om 18:37 schreef Marko Rauhamaa:
>> I see Python as doing the exact same thing with variables as C.
>>
>> What is different is that in Python, every expression evaluates to a
>> pointer. Thus, you can only assign pointers to variables.
>
> Then you think wrong. Python has no pointers, that is an
> implementation detail.

Call it what you want, but the semantics of Python is only
understandable through references (pointers, handles, leashes,
addresses) to objects. Furthermore, there is no expression in Python
that would evaluate to a reference to a variable. While variables may
(or may not) be objects, they definitely are *not* first-class objects
because of this important limitation.

> In python when you have two variables, and you assign one to the other
> you then have two variables that share an object.

When you say A and B "share" an object, I say A and B contain a pointer
(= reference) to the same object. It's simply a question of terminology,
although I haven't seen "sharing" used in this context. A "reference"
would be a great word (as in "reference counting"), but you recently
have wanted to use that word for variables.

> In C when you have two variables and you assign one to the other you
> then have two variable each refering to their own object that are
> copies of each other.

Maybe you didn't quite understand what I have written above. In C,
expressions can evaluate to values of these types (simplified):

    int

    long

    double

    pointer

    struct

    void (debatable)

However, note that C does *not* have any expression that would evaluate
to an object of these types:

    char

    short

    float

    array

    function

Now, Python all expressions yield references:

    []         evaluates to a reference (= pointer) to a fresh empty array

    1 + 2      evaluates to a reference (= pointer) to an integer

    1 / 2      evaluates to a reference (= pointer) to a float

    ".".join   evaluates to a reference (= pointer) to a function

Both languages provide the syntax:

    lvalue = expression

In light of the languages' respective expression semantics, the
semantics of the assignment statements coincide. Both languages evaluate
the expression ("rvalue") and place the result in the left-hand slot
("lvalue").

> And yes that sharing of variables in python can be simulated by
> copying pointers in C.

A "pointer" is an abstract concept both in C and Python. C does have a
much richer pointer semantics than Python. For example, C provides
pointer arithmetics.

> Maybe the simularities between variables in python can be made
> isomorphic with a specific subset of pointer operations in C.

Now we are talking. "Isomorphic" is the only useful meaning of sameness.

> In a rather straight forward environment with classes/structs that
> have an x and y attribute, the following lines behave differently
> in C and Python.
>
>   A.x = 1;
>   A.y = 2;
>
>   B = A;
>
>   B.x = 3;
>   B.y = 4;
>
> In C the variable A will still be x:1, y:2.
> In Python the variable A will be x:3, y:4.
>
> So no, Python doesn't do the exact same thing with variables as C.

The difference is not in the variables but in the expressions. In
Python,

    1

evaluates to a pointer; in C, it evaluates to an int. Furthermore, in
Python,

    A

evaluates to a pointer; in C, it evaluates to a struct.


Marko

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

#109723

Op 09-06-16 om 11:19 schreef Marko Rauhamaa:
>
>> In a rather straight forward environment with classes/structs that
>> have an x and y attribute, the following lines behave differently
>> in C and Python.
>>
>>   A.x = 1;
>>   A.y = 2;
>>
>>   B = A;
>>
>>   B.x = 3;
>>   B.y = 4;
>>
>> In C the variable A will still be x:1, y:2.
>> In Python the variable A will be x:3, y:4.
>>
>> So no, Python doesn't do the exact same thing with variables as C.
> The difference is not in the variables but in the expressions. In
> Python,
>
>     1
>
> evaluates to a pointer; in C, it evaluates to an int. Furthermore, in
> Python,
>
>     A
>
> evaluates to a pointer; in C, it evaluates to a struct.

If a variable evaluates to something different, in different
languages, the variable don't do the exact same thing in
the different languages.

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

#109744

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

> Op 09-06-16 om 11:19 schreef Marko Rauhamaa:
>> The difference is not in the variables but in the expressions. In
>> Python,
>>
>>     1
>>
>> evaluates to a pointer; in C, it evaluates to an int. Furthermore, in
>> Python,
>>
>>     A
>>
>> evaluates to a pointer; in C, it evaluates to a struct.
>
> If a variable evaluates to something different, in different
> languages, the variable don't do the exact same thing in
> the different languages.

In fact, it turns out that the variables are evaluated identically in
both C and Python. In both cases, a variable evaluates to the value the
variable is holding at the moment.

However, since all Python expressions evaluate into pointers, there's no
way to assign anything but a pointer to a variable. In C, expression
evaluation is much more diverse, as is variable typing.

Since Python variable is always holding a pointer, its straightforward
evaluation results in a pointer, closing the circle.


Marko

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

#109732

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

>   A.x = 1;
>   A.y = 2;
> 
>   B = A;
> 
>   B.x = 3;
>   B.y = 4;
> 
> 
> In C the variable A will still be x:1, y:2.
> In Python the variable A will be x:3, y:4. 

But it would, if you had written instead:

A->x = 1;
A->y = 2;

B = A;

B->x = 3;
B->y = 4;

which backs indeed the C pointer analogy...


-- 
Julien Salort
Entia non sunt multiplicanda praeter necessitatem
http://www.juliensalort.org

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

#109736

Op 09-06-16 om 13:46 schreef Julien Salort:
> Antoon Pardon <antoon.pardon@rece.vub.ac.be> wrote:
>
>>   A.x = 1;
>>   A.y = 2;
>>
>>   B = A;
>>
>>   B.x = 3;
>>   B.y = 4;
>>
>>
>> In C the variable A will still be x:1, y:2.
>> In Python the variable A will be x:3, y:4. 
> But it would, if you had written instead:
>
> A->x = 1;
> A->y = 2;
>
> B = A;
>
> B->x = 3;
> B->y = 4;
>
> which backs indeed the C pointer analogy...

Yes, what is your point? I know there is a C pointer analogy with
Python variables. The fact that there is an analogy between C pointers
and Python variables, is not enough to conclude that C variables and
Python variables behave exactly the same.

Normal structs are a kind of variable too in C. If you have to
ignore those in order to show similarities, then the variables
in general don't behave exactly the same.

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

#109722

Marko Rauhamaa <marko@pacujo.net> writes:

> Antoon Pardon <antoon.pardon@rece.vub.ac.be>:
>
>> You can do something like that in simula, but only because
>> simula has two kinds of assignments. One kind that is
>> simular to python and one that is similar to C.
>> The one that is similar that python is the reference assignment.
>
> I see Python as doing the exact same thing with variables as C.

I'm not sure that's a good mental model of what's going on. A variable
declaration in C carries semantics of memory allocation to hold the
value. This isn't so in python

>
> What is different is that in Python, every expression evaluates to a
> pointer. Thus, you can only assign pointers to variables.
>

I don't think that's really right - every expression evaluates to an
object. Whether or not that object can be accessed through some variable
or not depends on how the expression is used.

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

#109740

Paul Rudin <paul.nospam@rudin.co.uk>:

> Marko Rauhamaa <marko@pacujo.net> writes:
>> What is different is that in Python, every expression evaluates to a
>> pointer. Thus, you can only assign pointers to variables.
>
> I don't think that's really right - every expression evaluates to an
> object.

The object is only an intermediate result; what is returned is a pointer
(to an object), without an exception. That's not a matter of
implementation. It's an essential part of Python's data model.

(However, since "pointer" is evokes passions among crowds, it is better
to use the neutral word "leash".)


Marko

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

#109752

Marko Rauhamaa <marko@pacujo.net> writes:

> Paul Rudin <paul.nospam@rudin.co.uk>:
>
>> Marko Rauhamaa <marko@pacujo.net> writes:
>>> What is different is that in Python, every expression evaluates to a
>>> pointer. Thus, you can only assign pointers to variables.
>>
>> I don't think that's really right - every expression evaluates to an
>> object.
>
> The object is only an intermediate result; what is returned is a pointer
> (to an object), without an exception. That's not a matter of
> implementation. It's an essential part of Python's data model.
>

Well - the language has no explicit notion of "pointer", so I'm not sure
it's really correct to say that it's an essential part of the data
model. The way variables are used to reference the objects associated
with them from time to time has some similarities with pointer semantics
in other languages. But actually it's better (IMO) to just talk in the
terms the language specification uses. 

There are names and objects, and mechanisms by which names come to refer
to objects according to the execution model.


> (However, since "pointer" is evokes passions among crowds, it is better
> to use the neutral word "leash".)


Talk of pointers is potentially confusing, because it carries baggage
from other languages which doesn't necessary map precisely onto the
python execution model.


(The underlying cpython implementation, is neither here nor there - we
could in theory implement python in some other language which lacks a
pointer type.)

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

#109753

Paul Rudin <paul.nospam@rudin.co.uk>:

> Marko Rauhamaa <marko@pacujo.net> writes:
>> The object is only an intermediate result; what is returned is a
>> pointer (to an object), without an exception. That's not a matter of
>> implementation. It's an essential part of Python's data model.
>
> Well - the language has no explicit notion of "pointer", [...] it's
> better (IMO) to just talk in the terms the language specification
> uses.

The spec (<URL: https://docs.python.org/3/reference/datamodel.html>)
uses the terms *identity* and *reference*, which are one-to-one.

> There are names and objects, and mechanisms by which names come to
> refer to objects according to the execution model.

The spec as well as Python itself uses the word "name" for various
strings:

   >>> "x".__class__.__name__
   'str'
   >>> __name__
   '__main__'


So your "names" are *variables*.

Your "mechanisms" are *references*.

Your "objects" are *objects*.

> Talk of pointers is potentially confusing, because it carries baggage
> from other languages which doesn't necessary map precisely onto the
> python execution model.

Unfortunately, virtually every word is overloaded and full of
preconceived notions. Hence: "pegs", "leashes", "puppies".

The main thing is to keep those three concepts apart from each other.
Two notions will not suffice.


Marko

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

#109755

Marko Rauhamaa <marko@pacujo.net> writes:

> Paul Rudin <paul.nospam@rudin.co.uk>:
>
>> Marko Rauhamaa <marko@pacujo.net> writes:
>>> The object is only an intermediate result; what is returned is a
>>> pointer (to an object), without an exception. That's not a matter of
>>> implementation. It's an essential part of Python's data model.
>>
>> Well - the language has no explicit notion of "pointer", [...] it's
>> better (IMO) to just talk in the terms the language specification
>> uses.
>
> The spec (<URL: https://docs.python.org/3/reference/datamodel.html>)
> uses the terms *identity* and *reference*, which are one-to-one.

identity isn't the same thing as a name, identity is an inherent
property of an object - many names may refer to the same object.

Similarly reference doesn't mean the same thing as identity. A reference
to an object can occur, for example:

["foo"]

The list refers to the string. There's no name involved anywhere. Both
the list and the string have an identity, but that's essentially
irrelevant to the fact that the list has a reference to the string.

>
>> There are names and objects, and mechanisms by which names come to
>> refer to objects according to the execution model.
>
> The spec as well as Python itself uses the word "name" for various
> strings:
>
>    >>> "x".__class__.__name__
>    'str'
>    >>> __name__
>    '__main__'
>

__name__ is not the same thing as what the spec means when it talks of a
name.

It's certainly true that a class declaration creates a binding from that
name to an object representing the class. But other names can equally
well refer to the same object:

>>> class Foo:
...     pass
... 
>>> Bar = Foo
>>> x = Bar()
>>> x.__class__.__name__
'Foo'
>>>

>
> So your "names" are *variables*.

Informally yes, but "variable" has no meaning in the language reference.

>
> Your "mechanisms" are *references*.
>

Nope - when I spoke of mechanisms I was talking about the different
operational semantics by which a given names can be bound to an object.

Once such an binding has occured then I agree that the name refers to
the object in question.

> Your "objects" are *objects*.
>

I think I probably agree, but I'm not sure what you're saying - "object"
means something in the language reference - that's what I'm talking
about.


>> Talk of pointers is potentially confusing, because it carries baggage
>> from other languages which doesn't necessary map precisely onto the
>> python execution model.
>
> Unfortunately, virtually every word is overloaded and full of
> preconceived notions. Hence: "pegs", "leashes", "puppies".
>
> The main thing is to keep those three concepts apart from each other.
> Two notions will not suffice.
>

Well - adding more things is confusing in IMO - we have a language
reference, let's just use the terms in the language reference.

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

#109756

Paul Rudin <paul.nospam@rudin.co.uk> writes:

> Marko Rauhamaa <marko@pacujo.net> writes:

>> So your "names" are *variables*.
>
> Informally yes, but "variable" has no meaning in the language reference.
>

... err sorry, actually not correct - but irrelevant to the point under
discussion.

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

#109762

Paul Rudin <paul.nospam@rudin.co.uk>:

> Marko Rauhamaa <marko@pacujo.net> writes:
>> The spec (<URL: https://docs.python.org/3/reference/datamodel.html>)
>> uses the terms *identity* and *reference*, which are one-to-one.
>
> identity isn't the same thing as a name, identity is an inherent
> property of an object - many names may refer to the same object.

    x is y    if and only if    id(x) == id(y)

However, sorry for muddling the discussion by bringing in the identity.
I'll leave it out for now.

>> So your "names" are *variables*.
>
> Informally yes, but "variable" has no meaning in the language reference.

Really? How do you interpret these, then?

   Although the definition of assignment implies that overlaps between
   the left-hand side and the right-hand side are ‘simultaneous’ (for
   example a, b = b, a swaps two variables), overlaps within the
   collection of assigned-to variables occur left-to-right, sometimes
   resulting in confusion.

   <URL: https://docs.python.org/3/reference/simple_stmts.html?#assignme
   nt-statements>


   Assignments to __debug__ are illegal. The value for the built-in
   variable is determined when the interpreter starts.

   <URL: https://docs.python.org/3/reference/simple_stmts.html?#the-asse
   rt-statement>


   The public names defined by a module are determined by checking the
   module’s namespace for a variable named __all__

   <URL: https://docs.python.org/3/reference/simple_stmts.html?#the-impo
   rt-statement>

   It would be impossible to assign to a global variable without global,
   although free variables may refer to globals without being declared
   global.

   <URL: https://docs.python.org/3/reference/simple_stmts.html?#the-glob
   al-statement>

>> Unfortunately, virtually every word is overloaded and full of
>> preconceived notions. Hence: "pegs", "leashes", "puppies".
>>
>> The main thing is to keep those three concepts apart from each other.
>> Two notions will not suffice.
>
> Well - adding more things is confusing in IMO - we have a language
> reference, let's just use the terms in the language reference.

I have quoted "the language reference" quite a bit. Your turn.

You would be correct that there is something of an faux elitism going
around that is influencing the language spec as well to a degree. It
appears some people consider "variables," "assignments," "pointers" etc
to be too riff-raff. So people want to say Python is unlike C and has
"names," "bindings," "references" etc.

There's no shame in stating directly that Python has variables just like
C even though Python's variables are not first-class. There's no
difference between binding and assignment. And a reference is a synonym
to a pointer.

Python still has good stuff C doesn't, or even Java.


Marko

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

#109772

Marko Rauhamaa writes:
> Paul Rudin wrote:

>> Talk of pointers is potentially confusing, because it carries baggage
>> from other languages which doesn't necessary map precisely onto the
>> python execution model.
>
> Unfortunately, virtually every word is overloaded and full of
> preconceived notions. Hence: "pegs", "leashes", "puppies".
>
> The main thing is to keep those three concepts apart from each other.
> Two notions will not suffice.

Does a new leash appear when a puppy is tied to a peg? Apparently.

Is it possible to tie two puppies to the same peg? Apparently not. Why
not?

Is the leash left dangling in the neck of a puppy if another puppy is
tied to its peg? What if the puppy is tied again to the same peg, is
there then the new leash from its neck to the peg, and the old leash
left dangling?

Is it possible to leave the leash tied to the peg but untie the puppy?
Apparently not.

It's also not possible to look at the puppy and follow all the leashes
to find all the pegs where the puppy is tied.

The real third thing is not a thing but a relationship: being tied to.

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

#109759

On Thu, Jun 9, 2016, at 03:30, Antoon Pardon wrote:
> Then you think wrong. Python has no pointers, that is an implementation
> detail.

Nonsense. A binary number referring to a memory address is an
implementation detail. A pointer/reference/arrow-thingy-on-a-diagram is
the thing it is an implementation detail *of*.

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

#109684

On 08/06/2016 15:18, Antoon Pardon wrote:
> Op 08-06-16 om 14:34 schreef BartC:
>>
>> So you have partial updates and full updates. A proper reference will
>> be able to do both via the reference. Python can only do a partial
>> update and the reason is that the reference points to the object, not
>> the variable; there is no way to change the variable to link it with
>> another, distinct object.
>>
>> If the object is a list, then that can be modified to any extent, even
>> replacing the contents completely, but it will still be a list. In the
>> case of an int or string, then it's impossible to change. So there are
>> limitations to what can be done.
>>
>> Getting back to Pascal (as I /can/ remember how reference parameters
>> work for integers), assigning to a reference integer parameter in a
>> function will change the caller's version. Python can only emulate
>> that by passing a one-element list or using some such trick. Affecting
>> readability and, likely, performance.
>>
> I don't see why we should determine what a /proper/ reference
> can do, based on what it does in one specific language.

Because there are some things that such references can do that Python 
can't do with its object reference model, not without some difficulty or 
having to write convoluted code.

And it doesn't really depend on the language as the differences are easy 
to demonstrate, provided the language still has something along the 
lines of:

   a = b

to do normal assignment.

(1) Reference parameters

    def fn(&x):
       x=1000

    a="ABC"
    fn(a)

    print (a)    # should produce 1000

I've used "&" here as a device to make the 'x' param work as though it 
was passed by reference. That is, an /additional/ reference to the one 
Python might already use behind the scenes.

(2) Replace (not just modify) a variable's value and type indirectly

   a = 17
   p = &a

   *p = "Dog"
   print a      # should be "Dog"

Here "&" and "*" are used to indicate possible 'reference'/dereference 
operations.

With the last example, then this Python code:

   a = 17
   p = a

Might result in the following internal structures:

   0x300:a:[pyref:0x10020]             Variable
   0x400:p:[pyref:0x10020]             Variable
   0x10020:[int: 17]                   Object

With the p = &a version, it would be more like:

   0x300:a:[pyref:0x10020]             Variable
   0x400:p:[pyref:0x10040]             Variable
   0x10020:[int: 17]                   Object
   0x10040:[varref: 0x300]             Object

It's that 0x300 reference to 'a' itself, not just the object linked to 
it, that is what Python can't do.

-- 
Bartc

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

#109706

Op 08-06-16 om 19:29 schreef BartC:
> I don't see why we should determine what a /proper/ reference
>> can do, based on what it does in one specific language.
>
> Because there are some things that such references can do that Python
> can't do with its object reference model, not without some difficulty
> or having to write convoluted code.

So? Maybe you have the wrong idea of what a reference is/can do?
A reference is an alias. What you can do with that depends of the
work environment. That you can do different things in an evironment
that has a copy assignment than in an environment where you don't
doesn't make the aliases go away.

-- 
Antoon Pardon

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

#109713

On 09/06/2016 08:50, Antoon Pardon wrote:
> Op 08-06-16 om 19:29 schreef BartC:
>> I don't see why we should determine what a /proper/ reference
>>> can do, based on what it does in one specific language.
>>
>> Because there are some things that such references can do that Python
>> can't do with its object reference model, not without some difficulty
>> or having to write convoluted code.
>
> So? Maybe you have the wrong idea of what a reference is/can do?

Maybe. Maybe in all the languages I've been implementing for three 
decades have implemented references and pointers wrongly.

> A reference is an alias.

Not really. My address is not an alias for my house (the latter is a 
2-storey brick building, the former is a few lines on an envelope). A 
reference and what it refers to are a little different.

(What /I/ call an alias is demonstrated by a language feature I used to 
implement like this:

    int a
    int b @ a

    a := 18
    println b      # 18
    b := 21
    println a      # 21

Here, b is a synonym for a; another name for the same variable.)

> What you can do with that depends of the
> work environment. That you can do different things in an evironment
> that has a copy assignment than in an environment where you don't
> doesn't make the aliases go away.

Well, all my implementations of references and pointers meet Steven 
D'Apranso' swap() challenge (see his post in this thread about 90 
minutes before this one).

And in fact, my new languages have a built-in swap operator that 
internally depends on the kinds of references that Python doesn't have.

-- 
Bartc

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

#109719

Op 09-06-16 om 11:10 schreef BartC:
> On 09/06/2016 08:50, Antoon Pardon wrote:
>> Op 08-06-16 om 19:29 schreef BartC:
>>> I don't see why we should determine what a /proper/ reference
>>>> can do, based on what it does in one specific language.
>>>
>>> Because there are some things that such references can do that Python
>>> can't do with its object reference model, not without some difficulty
>>> or having to write convoluted code.
>>
>> So? Maybe you have the wrong idea of what a reference is/can do?
>
> Maybe. Maybe in all the languages I've been implementing for three
> decades have implemented references and pointers wrongly.

Then I assume you haven't heard of smalltalk.

> Well, all my implementations of references and pointers meet Steven
> D'Apranso' swap() challenge (see his post in this thread about 90
> minutes before this one).

Yes and that seems to confuses assignments with mutations.
The swap challenge is based on the assumptions that assignment
mutates.

You and Steven are expecting particular behaviour from the assignment
that is acutually depending on behaviour that mutates. So if the assignment
doesn't mutate, you can't expect that behaviour from an assignment.

-- 
Antoon Pardon

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

#109726

On 09/06/2016 10:55, Antoon Pardon wrote:
> Op 09-06-16 om 11:10 schreef BartC:
>> On 09/06/2016 08:50, Antoon Pardon wrote:
>>> Op 08-06-16 om 19:29 schreef BartC:
>>>> I don't see why we should determine what a /proper/ reference
>>>>> can do, based on what it does in one specific language.
>>>>
>>>> Because there are some things that such references can do that Python
>>>> can't do with its object reference model, not without some difficulty
>>>> or having to write convoluted code.
>>>
>>> So? Maybe you have the wrong idea of what a reference is/can do?
>>
>> Maybe. Maybe in all the languages I've been implementing for three
>> decades have implemented references and pointers wrongly.
>
> Then I assume you haven't heard of smalltalk.
>
>> Well, all my implementations of references and pointers meet Steven
>> D'Apranso' swap() challenge (see his post in this thread about 90
>> minutes before this one).
>
> Yes and that seems to confuses assignments with mutations.
> The swap challenge is based on the assumptions that assignment
> mutates.
>
> You and Steven are expecting particular behaviour from the assignment
> that is acutually depending on behaviour that mutates. So if the assignment
> doesn't mutate, you can't expect that behaviour from an assignment.
>

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.

(A good thing as I've lost track of what it is you are arguing about! 
Are you staying references exist or they don't, that Python has them or 
it hasn't, or what?

Meanwhile those of us of who sometimes have to implement these things 
can just get on with it.)

-- 
Bartc

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

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

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

csiph-web