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/ -- http://mail.python.org/mailman/listinfo/python-list
