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

#109520

On Sun, Jun 5, 2016, at 02:37, Steven D'Aprano wrote:
> No they don't. You are confusing the implementation with the programming
> model.
> 
> Following the assignment:
> 
> x = 99
> 
> if you print(x), do you see something like "reference 0x12345"? No.
> 
> Do you have to dereference that reference to get the value of x? No.
>
> At the Python level, the value of x is 99, not some invisible,
> untouchable reference to 99.

Sure, but that is the value of the object referenced by x, it is not a
property of x itself.

x = y = 999; z = int('999')
x is y # True
x is z # False

How would you describe the difference between x and y, and z? This is
not a mere implementation detail [though, the fact that for int in
particular I had to go higher than 99 to get this result is - I wouldn't
have had this problem with strings, and I *couldn't* have had this
problem with lists]. The fact that two objects can have the same value
while being different objects, and that two variables can point to the
same object, are part of the programming model. Immutable objects do
tend to blur the line, since implementations are permitted to make them
the same even when they're apparently independent.

The fact that == is an operator distinct from 'is' inherently means that
variables contain references, not objects.

There is, obviously, only one value in my example. If variables
contained objects, then my example would have three objects, none more
or less distinct. They contain references, and that is the only way
there are two objects, and that is the only model in which there are two
of anything.

[but, hey, at least we can agree that Python has variables.]

> There is no analog to dereferencing in Python, nothing like print(x^).

I don't see where anyone said there was. I think you've inferred meaning
to the statement "python variables contain references" that it does not
actually have.

> You bind values (that is, objects)

Values are not objects. x and z have the same value, and their objects
are identical but distinct, but they are different because they point
(or refer, or by your weird terminology "bind") to different objects.

> directly to names, and names (variables) hold their value, not a
> reference to their value.

They hold a reference to an object. The object holds the value.

> The fact that for some implementations that is implemented using
> references of some sort or another (e.g. pointers in CPython) is an
> implementation detail which is irrelevant to the language and its
> execution model.

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

#109525

Random832 <random832@fastmail.com>:

> On Sun, Jun 5, 2016, at 02:37, Steven D'Aprano wrote:
>> You bind values (that is, objects)
>
> Values are not objects. x and z have the same value, and their objects
> are identical but distinct, but they are different because they point
> (or refer, or by your weird terminology "bind") to different objects.

Terminological disputes are not very useful. However, note that your
use of the word "value" is not the only one:

   Assignment statements are used to (re)bind names to values and to
   modify attributes or items of mutable objects
   <URL: https://docs.python.org/3/reference/simple_stmts.h
   tml#assignment-statements>

   The returned value (if any) is used as an argument to construct
   StopIteration and becomes the StopIteration.value attribute.
   <URL: https://docs.python.org/3/reference/simple_stmts.h
   tml#the-return-statement>

   The type of the exception is the exception instance’s class, the
   value is the instance itself.
   <URL: https://docs.python.org/3/reference/simple_stmts.htm
   l#the-raise-statement>

while on the other hand,

   Every object has an identity, a type and a value.
   <URL: https://docs.python.org/3/reference/datamodel.htm
   l#objects-values-and-types>

   The operators <, >, ==, >=, <=, and != compare the values of two
   objects. The objects do not need to have the same type.
   <URL: https://docs.python.org/3/reference/expressions.htm
   l#value-comparisons>

IOW, sometimes the word "value" is a synonym of "object," at other times
it refers to the specific characteristics of an object. The latter
concept is not defined very clearly:

   The value of some objects can change. Objects whose value can change
   are said to be mutable; objects whose value is unchangeable once they
   are created are called immutable. (The value of an immutable
   container object that contains a reference to a mutable object can
   change when the latter’s value is changed; however the container is
   still considered immutable, because the collection of objects it
   contains cannot be changed. So, immutability is not strictly the same
   as having an unchangeable value, it is more subtle.) An object’s
   mutability is determined by its type; for instance, numbers, strings
   and tuples are immutable, while dictionaries and lists are mutable.
   <URL: https://docs.python.org/3/reference/datamodel.html#objec
   ts-values-and-types>


Marko

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

#109536

On Mon, 6 Jun 2016 03:42 am, Random832 wrote:

> On Sun, Jun 5, 2016, at 02:37, Steven D'Aprano wrote:
>> No they don't. You are confusing the implementation with the programming
>> model.
>> 
>> Following the assignment:
>> 
>> x = 99
>> 
>> if you print(x), do you see something like "reference 0x12345"? No.
>> 
>> Do you have to dereference that reference to get the value of x? No.
>>
>> At the Python level, the value of x is 99, not some invisible,
>> untouchable reference to 99.
> 
> Sure, but that is the value of the object referenced by x, it is not a
> property of x itself.

You need to be clear about what you are referring to.

x itself is the object 99. When we say "x + 1", we expect to get 100. x is
not some reference to 99, it is 99, just like Barrack Obama is not a
reference to the President of the United States, he is the POTUS.

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". Its
implementation in Python is likely to be a str, "x", used as a key in some
namespace (often a dict). The name itself doesn't have any numeric value,
just as the English words "Barrack Obama" themselves are not a person.

There are contexts where we need to refer to names themselves in Python, but
they are comparatively rare. You will usually recognise them from context,
occasionally implicitly, but usually explicitly by talking about "the name
x" or "x" in quotes rather than x. In code, it will usually involve eval or
exec, or sometimes a namespace lookup:

    method = vars(self)[methodname.upper()]


Likewise, it is rare to refer to the words rather than the person Barrack
Obama, but when you do, it is usually easy to recognise because you will
generally refer to "Barrack Obama" in quotes.

We might say:

    "x" is a single-letter name and x is an int one less than 100

but you normally wouldn't say:

    x is a single-letter name and x is an int one less than 100

unless your aim is to cause confusion.

This is no different from the issue in plain English that words have
meaning, and when we use a word, we normally expect them to be interpreted
according to that meaning, and rarely as an abstract word. When we do, we
normally put it in quotation marks, or explicitly state that we are
referring to it as a word:

A cat is a four-legged carnivorous mammal that purrs. "Cat" is a
three-letter word; the word cat is of unknown origin.



> x = y = 999; z = int('999')
> x is y # True
> x is z # False
> 
> How would you describe the difference between x and y, and z? 

The names x and y are bound to the same object. The name z is bound to a
distinct object with equal value.


> This is not a mere implementation detail 

Of course it is. An implementation might be clever enough to recognise that
int('999') is the same as 999 and reuse the same int object. An
implementation might cache *all* ints, regardless of size, or do no caching
at all. The part of that example which is not implementation defined is
that given x = y = 999, the language requires that x and y be the same
object.


> [though, the fact that for int in 
> particular I had to go higher than 99 to get this result is - I wouldn't
> have had this problem with strings,

Really?

py> a = b = "cat"; c = str("cat")
py> a is b is c
True

But again, this is an implementation detail. The caching of strings depends
on the version and implementation, and the string itself.


> and I *couldn't* have had this 
> problem with lists]. The fact that two objects can have the same value
> while being different objects, and that two variables can point to the
> same object, are part of the programming model.

Right. But that's actually not relevant to the question.


[...]
> The fact that == is an operator distinct from 'is' inherently means that
> variables contain references, not objects.

No, you are mixing levels of explanation and conflating implementation and
interface. Would you insist that because we can say that the words Barack
Obama contain eleven letters that the the United States has two words as a
president? That Michelle Obama is married to two words rather than a man?

Of course not. At least, if you are going to make that argument, then you
are so confused that I'm not even going to discuss this with you.

Imagine a horrendously memory profligate implementation that implemented
variables using the fixed memory location model "variables are boxes". When
I write:

x = y = 999; z = 999

the interpreter creates three boxes "x", "y", "z". All three boxes need to
be big enough for an int object, which in this case is about 12 bytes.
Actually a bit bigger, as you will see: let's say 16 bytes, because the
implementation needs (say) four bytes for an object identity tag. All three
boxes get *mostly* the same content, namely the 12 byte object 999, but the
x and y boxes get the identity tag (lets say) 633988994, and the z box gets
the identity tag 633988995.

`x == y` is implemented the usual way (calling int.__eq__), while `x is y`
is implemented by testing whether the first four bytes of each box are
equal.

This would be a horribly profligate (and slow) implementation. Parameter
passing into functions would occur via copying; it would be even more
horribly slow because every mutation to an object would require a scan of
all the objects, so as to update all of the boxes. But speed and efficiency
is not part of the Python language model, its a quality of implementation
issue, and besides, Moore's Law will make everything fast eventually.
(Wishful thinking.)

As inefficient and awful as this module is, it would still be Python, as the
interface (the programming model) is the same. (Give or take a few bugs.)


> There is, obviously, only one value in my example. 

There is nothing "obvious" about that at all. There is only one abstract
number in use, namely 999, but there are two objects. What counts as the
value? Is it the object, or the numeric value?

Before you answer, consider the value of x and y given:

x = Widget(part='123xy', colour='red')
y = x.copy()

just to make it clear that they are distinct objects. I would be unhappy
with any definition of "value" that says that x and y don't have values,
just because they are Widgets rather than strings or numbers, or the values
are undefined.

The question "the value of x?" is tricky, as we have to decide whether we
mean the value of the variable or the value of the object. The value of the
variable, I believe, must be identified with the object bound to that
variable. What else could it be? Surely we would want:

w = 999+0j
x = 999
y = 999.0
z = Decimal("999.0000")

to be distinguished: the variables aren't the same, they are bound to
objects of different types, and surely we want "the value of w" to be
understood as different from "the value of x" at least sometimes.

Those four variables are numerically equal, but may not even compare equal,
e.g. Decimal("999.0") == 999.0 returns False in 2.5. In principle, two
numerically equal values might even raise TypeError on comparison. So there
is nothing *obvious* about talking about value.

I think that, under usual circumstances, the best way to understand "the
value of x" is to distinguish between two cases: if x refers to the name,
normally written "the value of the variable 'x'" but sometimes implied by
the context, then the answer should be the object bound to 'x'. But if x
refers to the variable, as in "the value of x", it refers to some
type-specific definition of value, e.g. the numeric value.

So your example has two values, which happen to be equal as they have the
same, er, numeric value. (Sometimes words get used with different contexts.
We need more words.)


> If variables 
> contained objects, then my example would have three objects,

Certainly not. x = y = 999 is required to bind the same object to x and y.


> none more or less distinct. They contain references, 

If your variable x were a reference, then we would expect type(x) to return
something like "Reference", but it doesn't, it returns int.

(Why do I say this? We say "x is an int" after "x = 999", and type(x)
returns int. So if "x is a reference", then type(x) ought to return
Reference. If you *don't* say "x is an int", well, frankly, I don't believe
you. See below.)

If x were a reference to 999, then we would need to dereference x to get to
the 999, but we don't. We don't write:

    print(dereference(x) + 1)


to get 1000, we write print(x+1). If x + 1 is 1000, what is the value of x?

(a) 999
(b) some invisible, intangible, untouchable reference to 999


If your answer is (b), then your view of Python programming is obfuscatory
and muddled and I cannot understand how you can effectively reason about
your code. If you look at an expression like 

    x.y.z['k'] = [999]

and reason like this:

    "x is a reference to a Spam object, so x.y is a reference to a reference
    to an Eggs object, so x.y.z is a reference to a reference to a reference
    to a dict, so x.y.z['k'] is a reference to a reference to a reference 
    to a dict containing a reference to a key 'k' which maps to a reference
    to a list containing a reference to 999."


then I cannot imagine how you get any work done. I don't believe you do. I
believe you reason about the code just like I do:

    "x is a Spam object, so x.y is an Eggs object, so x.y.z is a dict, so
    x.y.z['k'] is a dict with key 'k' which maps to a list containing 999."


So I'll be frank: anyone who says that "variables are references" surely
doesn't behave as if that were true. They don't program as if variables
were references, they don't reason about the code as if the variables were
references, and they certainly don't talk about code as if they were
references. They behave as if variables are the values (objects) bound to
them, just as I have argued all along.

(Except for the occasional and unusual situation where "peeking under the
bonnet" into the implementation actually is helpful -- such cases do exist,
such as a list which contains itself. Python's object model is an
abstraction, and all abstractions leak. Sometimes we cannot help but talk
about the implementation, in order to understand the leaks.)


>> There is no analog to dereferencing in Python, nothing like print(x^).
> 
> I don't see where anyone said there was. I think you've inferred meaning
> to the statement "python variables contain references" that it does not
> actually have.

Of course it does, if you are talking about the Python variable model rather
than the implementation.

I'm perfectly happy for people to say that Python variables are implemented
as references to objects. That's completely unobjectional, as it is true
for all implementations I know of, and it will likely be true for any
future implementations as well. We can be even more concrete and say that
CPython variables are implemented as pointers to objects.

But that's not the same as talking about the Python model. If you look at
Python code, and read "x = 999", and don't think of x as now being 999,
then I cannot fathom your mindset. You're thinking about code is an
obfuscatory manner that is of no use to me.

(In that case, I wonder why you don't go all the way to thinking about x as
some sequence of bits: in Python 2.7, 96 bits.)


>> You bind values (that is, objects)
> 
> Values are not objects. x and z have the same value, and their objects
> are identical but distinct,

"Identical but distinct" is a contradiction according to the way object
identity is defined in Python.


> but they are different because they point 
> (or refer, or by your weird terminology "bind") to different objects. 

"Bind" is not weird terminology. It is a standard term in widespread use in
computer science, particularly object oriented languages.

https://en.wikipedia.org/wiki/Name_binding

https://en.wikipedia.org/wiki/Late_binding

https://en.wikipedia.org/wiki/Binding#In_computing



-- 
Steven

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

#109538

On Sun, Jun 5, 2016, at 23:52, Steven D'Aprano wrote:
> Certainly not. x = y = 999 is required to bind the same object to x and
> y.

My statement was that if two variables can be bound to the same object,
then variables *cannot* contain objects. The object has to exist
somewhere, and this requirement means that the variables cannot be where
the objects live.

> If your variable x were a reference, then we would expect type(x) to
> return
> something like "Reference", but it doesn't, it returns int.

No we would not. You are once again inferring meaning that people's
statements don't actually carry.

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

#109574

On Mon, 6 Jun 2016 02:08 pm, Random832 wrote:

> On Sun, Jun 5, 2016, at 23:52, Steven D'Aprano wrote:
>> Certainly not. x = y = 999 is required to bind the same object to x and
>> y.
> 
> My statement was that if two variables can be bound to the same object,
> then variables *cannot* contain objects. The object has to exist
> somewhere,

I could dispute that assertion, e.g. consider what happens when you simulate
a Python interpreter in your brain. What is the location of the objects
then? As best as we can tell from neuroscience, memories are distributed
across fairly large swaths of neurons.

But that's not the point. Even if you were right that objects must exist at
a single well-defined location, that is strictly irrelevant. That's
implementation, not interface. There is nothing in the specification of the
Python virtual machine and the execution model that requires objects have a
single location. That's just the way they happen to be easy to write on
current generation computers.


> and this requirement means that the variables cannot be where 
> the objects live.

I don't care. That's just implementation. There is nothing in the Python
programming language that says "x = 999" makes x an indirect reference to
999. The very thought is absurd.

I have tried to see things from your perspective. I completely agree that,
at the implementation level, Python variables are implemented as references
(in CPython, pointers) to objects. We all agree on that. Yay! We have
partial agreement!

But it really, truly is absurd to insist that AT THE PYTHON LEVEL variables
are references. That's as foolish as insisting that the President of the
United States is two words with eleven letters, not a man.

Surely you can acknowledge that the language we use to explain things will
depend on the level of physical phenomena we are looking at? If we can't
agree on that, then there's no point in continuing this conversation.

At the Python virtual machine level, x is the object 999. This is the most
important level, because we're actually talking about Python code. The
whole point of this is to understand what the Python VM does, so we can
reason about code. Every thing else is, in general, obfuscation, to a
lesser or greater degree.

At the C implementation level, x is an entry in a hash table, a pointer
pointing at an object in the heap. Occasionally it is useful to bring the
discussion down to this level, but not often.

At the assembly language level, x is probably a 32-bit or 64-bit word,
depending on whether you have a 32-bit or 64-bit build. Assigning to a
variable is a matter of copying memory from one location to another.

At a lower level still (machine code? microcode?), we don't copy memory, we
flip bits. x will be a series of bits. There's not much interesting to say
at this level: whether x is 999 or a HTTPServer object or None, it's still
just a series of bits.

At the hardware level, considered as a DRAM unit (other types of memory use
different implementations), x is a set of microscopic capacitors holding
tiny electric charges representing either a "high" or "low" charge, i.e.
bits.

At the hardware level below that, we have to start talking about the
properties of impure silicon, electrons in atomic shells, so-called
electron holes, etc. Given x = 999, x will be any of a large number of sets
of electron distributions, involving millions(?) of electrons. A few
thousand more or less in any one specific chunk of silicon will make no
difference: there are many, many physical states that x could be.

And below that, we start talking about quantum probability functions, and
surely we can agree that it is absurd to say that Python variables are
really quantum probability functions!

Can you at least met me there? Can we agree that, while it is absolutely
true and correct that Python variables are really implemented as quantum
waves, this fact is of absolutely no use to anyone trying to understand
what a snippet of Python code does?



>> If your variable x were a reference, then we would expect type(x) to
>> return
>> something like "Reference", but it doesn't, it returns int.
> 
> No we would not. You are once again inferring meaning that people's
> statements don't actually carry.

In the plain English meaning of the words, if is an int, then it behaves as
an int, and if you use introspection on it, it will look like an int. If x
is a string, then it similarly behaves as, and looks like, a string. So if
x is a reference, what should it behave as? A wheelbarrow?

I cannot help that you want to describe x as being a reference while denying
that it behaves as a reference or can be introspected as looking like a
reference. You could equally say it is really, actually a set of bits, or
charges in an integrated circuit, or electrons in atomic shells.


-- 
Steven

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

#109604

Steven D'Aprano wrote:
> Even if you were right that objects must exist at
> a single well-defined location, that is strictly irrelevant. That's
> implementation, not interface.

We're talking about mental models. Sure, you could come up
with some kind of Tardis-like mental model where objects
exist in more than one location at once. But why would
you bother going to such mental contortions? There is a much
more straightforward model that's vastly easier to reason
about, because it aligns with our intuitions, which are
based on the way things behave in the actual universe we
live in.

-- 
Greg

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

#109618

On Tuesday 07 June 2016 15:42, Gregory Ewing wrote:

> Steven D'Aprano wrote:
>> Even if you were right that objects must exist at
>> a single well-defined location, that is strictly irrelevant. That's
>> implementation, not interface.
> 
> We're talking about mental models. Sure, you could come up
> with some kind of Tardis-like mental model where objects
> exist in more than one location at once. But why would
> you bother going to such mental contortions?

Because (self-recursive data structures like lists that contain themselves 
aside), that's actually a much more simple mental model than the pointer model. 
Its how natural language works. Compare:

"Greg kicked the penguin."

with:

"The person whose name is Greg kicked the penguin."

Both say the same thing. The first uses the word 'Greg' as a direct stand-in 
for the person Greg himself, the man. 'Greg' (the word) is used to mean the 
person Greg, it is not used as "a word that refers to the person". 

The second emphasises the fact that 'Greg' is a name, not a person, and is a 
form of indirection. It uses 'Greg' as 'a word that refers to the person', not 
the person itself. We almost always prefer sentences of the first type rather 
than the second.

x = 999

Why should we say "x is a reference to 999" when "x is 999" is simpler, 
shorter, explains the semantics of the code, and is arguably more correct?

Given that in Python code, x behaves like an int, and looks like an int, and we 
treat it like an int, applying int operations such as + to it, and we discuss 
it as if it were an int, why on earth would we bother going to such mental 
contortions as to insist that its actually a reference?

Here's a thought experiment for you. Suppose in Python 3.6, Guido announces 
that Python will support a form of high-level pointer (not the scary, dangerous 
low-level pointer of C) called "reference". There will be a dereference 
operator, ^, and a "reference to" operator, @. We'll be able to treat 
references as first-class values:

x = 999
y = @x

print(y)
=> prints "ref --> 999"

print(type(y))
=> prints "reference"

print(y^ + 1)
=> prints 1000


Do we say:

"x is 999, and y is a reference to x"

or would you prefer:

"x is a reference to 999, and y is a reference to a reference to x"?


We users of languages like Python get all the advantages of references, dynamic 
allocation of variables, indirection etc. with none of the pain, or at least 
hardly any. We rarely need to care about the fact that the interpreter uses 
indirect references under the hood, because the Python language itself doesn't 
require us to care. When we assign "x = 999", we treat x as if it were an int, 
just like the code says it is. When we assign "x = []", we treat x as if it 
were a list, just like the code says. Why should we insist that x isn't 
actually an int, or a list, but an invisible, untouchable, unseen reference?


By the way, I believe that these people claiming that x is a reference do not, 
in general, use that language in real life. I would be willing to bet that you 
say "x is 999" just like I do.


-- 
Steve

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

#109624

Op 07-06-16 om 12:18 schreef Steven D'Aprano:
> We're talking about mental models. Sure, you could come up
> with some kind of Tardis-like mental model where objects
> exist in more than one location at once. But why would
> you bother going to such mental contortions?
> Because (self-recursive data structures like lists that contain themselves 
> aside), that's actually a much more simple mental model than the pointer model. 
> Its how natural language works. Compare:
>
> "Greg kicked the penguin."
>
> with:
>
> "The person whose name is Greg kicked the penguin."
>
> Both say the same thing. The first uses the word 'Greg' as a direct stand-in 
> for the person Greg himself, the man. 'Greg' (the word) is used to mean the 
> person Greg, it is not used as "a word that refers to the person". 
>
> The second emphasises the fact that 'Greg' is a name, not a person, and is a 
> form of indirection. It uses 'Greg' as 'a word that refers to the person', not 
> the person itself. We almost always prefer sentences of the first type rather 
> than the second.

Yes almost. But the second is more accurate and sometimes the extra accuracy
matters. Like often enough the difference between numbers and numerals when people
say they want to work with binary numbers.

> x = 999
>
> Why should we say "x is a reference to 999" when "x is 999" is simpler, 
> shorter, explains the semantics of the code, and is arguably more correct?
>
> Given that in Python code, x behaves like an int, and looks like an int, and we 
> treat it like an int, applying int operations such as + to it, and we discuss 
> it as if it were an int, why on earth would we bother going to such mental 
> contortions as to insist that its actually a reference?

Because you are putting blinders on by only looking at a simple type like an int.
By looking only at ints, you are totally obscuring the difference in asignment
semantics beween C and python. And by obscuring that difference you are inviting
the confused inquiries later, on whether argument passing in python is by value or
by reference.

Sure talk about "x is 999" when you are talking about a piece of code, but when
you are explaining assignment semantics or other particulars of the language
saying things like that is taking a shortcut that often enough will cause
confusions later.

> Here's a thought experiment for you. Suppose in Python 3.6, Guido announces 
> that Python will support a form of high-level pointer (not the scary, dangerous 
> low-level pointer of C) called "reference". There will be a dereference 
> operator, ^, and a "reference to" operator, @. We'll be able to treat 
> references as first-class values:

That makes very little sense in python.  

> We users of languages like Python get all the advantages of references, dynamic 
> allocation of variables, indirection etc. with none of the pain, or at least 
> hardly any. We rarely need to care about the fact that the interpreter uses 
> indirect references under the hood, because the Python language itself doesn't 
> require us to care. When we assign "x = 999", we treat x as if it were an int, 
> just like the code says it is. When we assign "x = []", we treat x as if it 
> were a list, just like the code says. Why should we insist that x isn't 
> actually an int, or a list, but an invisible, untouchable, unseen reference?

That doesn't change the fact that when you have to explain the language semantics,
making it clear that variables are essentials references and that an assigment
just changes such a reference and doesn't do a copy.

> By the way, I believe that these people claiming that x is a reference do not, 
> in general, use that language in real life. I would be willing to bet that you 
> say "x is 999" just like I do.

So what? People use shortcuts in language all the time, because often enough the
context makes it clear how the shortcut is to be understood. That people often
use the shortcut "x is 999" doesn't make the statement wrong that variables are
essentially references in Python. 

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

#109630

On Tue, 7 Jun 2016 10:32 pm, Antoon Pardon wrote:

> That people often use the shortcut "x is 999" doesn't make the statement
> wrong that variables are essentially references in Python.

No, I'm sorry, you're wrong, variables are essentially arrays of bits in
Python.



-- 
Steven

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

#109661

Op 07-06-16 om 18:03 schreef Steven D'Aprano:
> On Tue, 7 Jun 2016 10:32 pm, Antoon Pardon wrote:
>
>> That people often use the shortcut "x is 999" doesn't make the statement
>> wrong that variables are essentially references in Python.
> No, I'm sorry, you're wrong, variables are essentially arrays of bits in
> Python.

No they are not. The difference between variables as references and variables
as containers is an abstract notions that comes to light in the semantics
of the assignment, however these semantics are implemented.

Talking about arrays of bits is talking about a specific implementation. You
seem unable to think of a reference as an abstract model.

-- 
Antoon Pardon

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

#109629

On Tue, Jun 7, 2016, at 08:32, Antoon Pardon wrote:
> > Here's a thought experiment for you. Suppose in Python 3.6, Guido announces 
> > that Python will support a form of high-level pointer (not the scary, dangerous 
> > low-level pointer of C) called "reference". There will be a dereference 
> > operator, ^, and a "reference to" operator, @. We'll be able to treat 
> > references as first-class values:
> 
> That makes very little sense in python.  

Why not? If you prefer, think of it something like:

class ItemPtr:
   def __init__(self, obj, key):
      self.obj = obj
      self.key = key
   def ___setvalue___(self, value):
      self.obj[self.key] = value
   def ___getvalue___(self)
      return self.obj[self.key]

@(foo[bar]) returns ItemPtr(foo, bar)
@baz where bar is a global variable returns ItemPtr(globals(), 'baz')
@quux where quux is local returns a cell object (any local that is used
in such an expression becomes a cell variable as with any local that is
used in a closure), and the cell type shall have these methods added to
it.
@(foo.bar) returns AttrPtr(foo, 'bar') where AttrPtr is a similarly
defined type.

We could even support a kind of "pointer arithmetic" for ItemPtr to
list-like containers:

def __add__(self, offset):
    return ItemPtr(self.obj, self.key + offset)
def __getitem__(self, offset):
    return self.obj[self.key + offset]

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

#109660

Op 07-06-16 om 17:33 schreef Random832:
> On Tue, Jun 7, 2016, at 08:32, Antoon Pardon wrote:
>>> Here's a thought experiment for you. Suppose in Python 3.6, Guido announces 
>>> that Python will support a form of high-level pointer (not the scary, dangerous 
>>> low-level pointer of C) called "reference". There will be a dereference 
>>> operator, ^, and a "reference to" operator, @. We'll be able to treat 
>>> references as first-class values:
>> That makes very little sense in python.  
> Why not? If you prefer, think of it something like:

The fact that you can make it somehow work, doesn't mean it
makes much sense. If you don't like the limitation of the
assignment semantics in python, it seems more interresting
to change that, than to work around what we have now.

Python could go the simula route, which has two kinds of
assignment. One with the python semantics and one with C
semantics.

Let as use := for the C sematics assignment and <- for the
python sematics assignment. We could then do something like
the following.

ls := [5, 8, 13, 21]
a <- ls[2]
a := 34
print ls  # [5, 8, 34, 21]

Now it may very well be possible to achieve the same results
with what you have in mind, but in my mind it makes not much
sense in trying to achieve the semantics of a copy assignment
by building extra indirection on top of reference assignments.

-- 
Antoon Pardon

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

#109663

On Wednesday 08 June 2016 17:53, Antoon Pardon wrote:

> Python could go the simula route, which has two kinds of
> assignment. One with the python semantics and one with C
> semantics.
> 
> Let as use := for the C sematics assignment and <- for the
> python sematics assignment. We could then do something like
> the following.
> 
> ls := [5, 8, 13, 21]
> a <- ls[2]
> a := 34
> print ls  # [5, 8, 34, 21]

What you seem to be describing is similar to reference parameter semantics from 
Pascal. Assignment doesn't work that way in C, or Python. In C, pointers can be 
used to simulate those semantics, but you have to explicitly dereference the 
pointer when you assign.

Using C assignment, with an array:

# excuse any minor syntax errors, my C is rusty
int A[4] = {5, 8, 13, 21};
int n
n = A[2];
n = 34;

the array A does not change. Assignment *copies* the value into the variable. 
To get the semantics you are after, you need to use a pointer with an explicit 
dereference:

int *p;
p = &A[2];
*p = 34;

which will now change the value of the array. If you leave the dereference out:

p = 34;

you are setting p to point to address 34, whatever that is.

Now, the point is, in order to deserve the term "first class", you the 
programmer shouldn't have to care about manual dereferencing. In C, you do, so 
while you can get "reference variables" in C, they're only third class. In 
Pascal, they're second class, because you can get reference variables but only 
for function/procedure parameters. Pascal doesn't generalise that to allow 
references to any arbitrary variable.

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


although you can almost fake it using lists:

a = [1]
b = a
b[0] = 99
assert a == [99]


-- 
Steve

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

#109667

Op 08-06-16 om 10:47 schreef Steven D'Aprano:
> On Wednesday 08 June 2016 17:53, Antoon Pardon wrote:
>
>> Python could go the simula route, which has two kinds of
>> assignment. One with the python semantics and one with C
>> semantics.
>>
>> Let as use := for the C sematics assignment and <- for the
>> python sematics assignment. We could then do something like
>> the following.
>>
>> ls := [5, 8, 13, 21]
>> a <- ls[2]
>> a := 34
>> print ls  # [5, 8, 34, 21]
> 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.

> 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. If all
you have is reference variables and assignments just change what object is refered
to, you can't have such an effect either.

-- 
Antoon Pardon.

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

#109670

On 08/06/2016 10:41, Antoon Pardon wrote:
> Op 08-06-16 om 10:47 schreef Steven D'Aprano:
>> On Wednesday 08 June 2016 17:53, Antoon Pardon wrote:
>>
>>> Python could go the simula route, which has two kinds of
>>> assignment. One with the python semantics and one with C
>>> semantics.
>>>
>>> Let as use := for the C sematics assignment and <- for the
>>> python sematics assignment. We could then do something like
>>> the following.
>>>
>>> ls := [5, 8, 13, 21]
>>> a <- ls[2]
>>> a := 34
>>> print ls  # [5, 8, 34, 21]
>> 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]

(Did you mean range(4) and [0, 1, 5, 3]?)

> This is exactly the result you would get with B as a reference parameter in pascal.

I can't remember exactly how Pascal worked. But your assignment to B[2] 
is an in-place modification. That sort of thing Python can do (when 
allowed as some things are not mutable) with its existing reference system.

But a 'proper' reference allows a complete replacement of what it refers 
to. That would mean being able to do:

   B = "Cat"
   print A     # "Cat"

No tricks involving in-place updates such as assigning to list elements 
are needed.

-- 
Bartc

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

#109672

Op 08-06-16 om 12:33 schreef BartC:
> On 08/06/2016 10:41, Antoon Pardon wrote:
>> Op 08-06-16 om 10:47 schreef Steven D'Aprano:
>>> On Wednesday 08 June 2016 17:53, Antoon Pardon wrote:
>>>
>>>> Python could go the simula route, which has two kinds of
>>>> assignment. One with the python semantics and one with C
>>>> semantics.
>>>>
>>>> Let as use := for the C sematics assignment and <- for the
>>>> python sematics assignment. We could then do something like
>>>> the following.
>>>>
>>>> ls := [5, 8, 13, 21]
>>>> a <- ls[2]
>>>> a := 34
>>>> print ls  # [5, 8, 34, 21]
>>> 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]
>
> (Did you mean range(4) and [0, 1, 5, 3]?)

Yes, sorry about that.

>
> But a 'proper' reference allows a complete replacement of what it
> refers to. That would mean being able to do:
>
>   B = "Cat"
>   print A     # "Cat"
>
> No tricks involving in-place updates such as assigning to list
> elements are needed.

No it doesn't mean that. 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.

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]

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

#109673

On 08/06/2016 12:01, Antoon Pardon wrote:
> Op 08-06-16 om 12:33 schreef BartC:

>> But a 'proper' reference allows a complete replacement of what it
>> refers to. That would mean being able to do:
>>
>>   B = "Cat"
>>   print A     # "Cat"
>>
>> No tricks involving in-place updates such as assigning to list
>> elements are needed.
>
> No it doesn't mean that. 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.
>
> 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]

Well, it then becomes necessary to separate a mutating assignment 
(a[i]=b) where the left-hand-size modifies part of a larger object, from 
a full assignment (a=b) which replaces a whole object (the value of a) 
with another.

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.

-- 
Bartc

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

#109679

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.

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 don't see why the variables in python wouldn't be reference
variables, just because python lacks the "normal" assignment
from simula.

It is possible to write simula programs that almost exclusively
use reference assignments. Limiting yourself like that, would
also not allow you to do /proper/ referencing.

It seems weird to refuse to call something a /proper/ reference,
while what is missing is not a reference assignment but a
mutating assignment.

-- 
Antoon Pardon.

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

#109681

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.


Marko

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

#109694

On Thursday, June 9, 2016 at 4:37:58 AM UTC+12, Marko Rauhamaa wrote:
> 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.

Yup. I think some people are getting confused over assignment to simple variables as opposed to more complex expressions on the LHS of assignments in Python. For example, given

    a = [1, 2, 3, 4]

compare the different effects of

    b = a
    b = a[:]
    b[:] = a # assuming b already has an appropriate initial value

not to mention other possibilities...

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

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

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

csiph-web