On Thu, 16 Oct 2008 11:24:28 -0600, Joe Strout wrote:
> On Oct 16, 2008, at 10:59 AM, Larry Bates wrote:
>
>>> how do i find that the name is 'bob'
>>
>> Short answer is that you can't. This because Python's names (bob) are
>> bound to objects (modulename.objectname()). They are NOT variables as
>> they are in "other" programming languages.
>
> Which other programming languages? I've never seen an OOP language that
> didn't work the same way as Python.
>
> However, 'bob' here really is a variable. It's a variable whose value
> (at the moment) is a reference to some object.
Traditionally, a "variable" is a named memory location.
The main objection I have to using "variable" to describe Python name/
value bindings is that it has connotations that will confuse programmers
who are familiar with C-like languages. For example:
def inc(x):
x += 1
n = 1
inc(n)
assert n == 2
Why doesn't that work? This is completely mysterious to anyone expecting
C-like variables.
At this point people will often start confusing the issue by claiming
that "all Python variables are pointers", which is an *implementation
detail* in CPython but not in other implementations, like PyPy or Jython.
Or people will imagine that Python makes a copy of the variable when you
call a function. That's not true, and in fact Python explicitly promises
never to copy a value unless you explicitly tell it to, but it seems to
explain the above, at least until the programmer starts *assuming* call-
by-value behaviour and discovers this:
def inc(alist):
alist += [1] # or alist.append(1) if you prefer
return alist
a = [1, 2, 3]
b = inc(a)
assert a == [1, 2, 3]
Are functions call by value or call by reference???
(Answer: neither. They are call by name.)
I myself often talk about variables as shorthand. But it's a bad habit,
because it is misleading to anyone who thinks they know how variables
behave, so when I catch myself doing it I fix it and talk about name
bindings. Noobs might not know what that means, but that's a feature, not
a bug, because it gets them paying attention instead of making faulty
assumptions.
Of course, you're entitled to define "variable" any way you like, and
then insist that Python variables don't behave like variables in other
languages. Personally, I don't think that's helpful to anyone.
[snip]
> Well, they are variables. I'm not quite grasping the difficulty here...
> unless perhaps you were (at first) thinking of the variables as holding
> the object values, rather than the object references.
But that surely is what almost everyone will think, almost all the time.
Consider:
x = 5
y = x + 3
I'm pretty sure that nearly everyone will read it as "assign 5 to x, then
add 3 to x and assign the result to y" instead of:
"assign a reference to the object 5 to x, then dereference x to get the
object 5, add it to the object 3 giving the object 8, and assign a
reference to that result to y".
Of course that's what's really happening under the hood, and you can't
*properly* understand how Python behaves without understanding that. But
I'm pretty sure few people think that way naturally, especially noobs.
References are essentially like pointers, and learning pointers is
notoriously difficult for people. Python does a magnificent job of making
references easy, but it does so by almost always hiding the fact that it
uses references under the hood. That's why talk about variables is so
seductive and dangerous: Python's behaviour is *usually* identical to the
behaviour most newbies expect from a language with "variables".
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
