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

Steven D'Aprano steve+comp.lang.python at pearwood.info
Tue Jun 7 06:18:17 EDT 2016


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




More information about the Python-list mailing list