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