Return value of an assignment statement?

[Steve Holden]

Marc 'BlackJack' Rintsch wrote:
> On Fri, 22 Feb 2008 12:32:10 +0000, Steven D'Aprano wrote:
> 
>> On Fri, 22 Feb 2008 08:12:56 +0000, Marc 'BlackJack' Rintsch wrote:
>>
>>> A "variable" in programming languages is composed of a name, a memory
>>> location, possibly a type and a value. In C-like languages, where you
>>> put values in named and typed "boxes", the memory location and type are
>>> attached to the name.  In Python both belong to the value.
>> But Python objects don't have names, so by your own definition, they
>> aren't variables.
> 
> Exactly!  Names aren't variables.  The unit of a name, an address, and a
> value are a variable.
> 
>> Names are associated with namespaces, not objects. A name must have one
>> and only one object bound to it at any one time;
> 
> What is a binding when it's not an association between a name and an
> object!?  So names are associated with objects.  There are no names
> without objects in Python.  If a name is not bound to any object, how could
> the name exist?  That would be like a dangling pointer, a beast that
> doesn't exists in Python.
> 
> <nitpick>Okay there are local names that are known and therefore somehow
> "exist" before they get bound, but that's IMHO an implementation
> detail.<nitpick>
> 
>> objects on the other hand can be bound to one name, or no name, or a
>> thousand names. The object itself has no way of knowing what names it is
>> bound to, if any.
>>
>> Or, to put it another way... Python doesn't have variables.
> 
> It has.  You just can't substitute the term "name" with "variable" and
> expect it to behave like in C.  A variable is not just the name but also
> the value and the storage space and how those are connected.
> 
"Does" ... "Doesn't" ... "Does so!".

You guys are merely arguing about what you want to call the Python 
assignment semantics you both understand perfectly well. This isn't 
going to help anyone.

The fact of the matter is that when a Python name is bound to a value 
the value is normally created in heap storage (with a few exceptions 
like the pre-allocated objects such as None and the small integers, but 
*never* directly in the namespace in which the name is being bound), and 
the name is associated with a reference to the value.

I've said before that Python names are very similar to automatically 
dereferenced pointer variables, and I suppose the same old arguments 
will be trotted out against that utterance now I've said it again.

But for the purposes of comprehension, particularly by C and C++ 
programmers who haven't come across this particular semantic before it 
should server to aid comprehension. The fact that objects exist 
independent of the dynamically created scopes of function calls and the 
like is precisely what stops Python from suffering the same out-of-scope 
(dangling) pointer issues that C++ is famous for.

The fact remains that name binding in Python (and binding to container 
items too) doesn't "return a value", and bindings were deliberately not 
allowed as a term in a broader expression to avoid some common 
programming errors.

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC              http://www.holdenweb.com/