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

[Antoon Pardon]

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.