Magnus Lycka wrote: > Claudio Grondi wrote: > >> You seem here to try to give a definition of the term 'value' for >> Python. If I understand it right, the definition of the term can't be >> generally given for many reasons. It depends at least on type and in >> advanced usage it can be arbitrary defined or changed. >> That is why I mean, that it makes no sense to talk in Python about >> value. I see not much sense in taking existing term in order to >> redefine it for a new context - the result is always increase of >> confusion. Let give it another name in order to know, that it must be >> defined for the context it is used before it becomes meaningful. >> Any suggestions? > > > I think I understand what you mean. In e.g. C you have variables > with values. A variable is a location in memory where you can place > values of a certain type. > > This "world-view" doesn't fit if you want to understand Python. > > You always have three "thingies" in Python, instead of the two in > C. In C terminology you could say that you always use void pointers > in Python. (Of course, it's not as bad as it sounds, because of > all runtime checks and memory management etc, but you know that.) > > So, in Python you have references, objects and content. > > Sometimes the reference is just a slot in a container, e.g. if you > have "[0]" in your code, the list contains a reference to an > integer object with the content 0. > > I think most people consider "value" and "content" to be synonyms, > but from the perspective of a variable name in the source code, > e.g. "a='hello'", there is always one level of indirection, since > there is always a pointer in between (and you can get that with > "id(a)"). > > The Python manuals refer to the names in Python programs (such as > "a" in "a=1") as variables, but some think that it's better to > call them "names" or "references", since they lack properties many > people associate with variables, for instance type. > > If I return to C lingo again, datastructures in Python are always > made with malloc, and it's just these datastructures on the heap > that contain interesting values (or contents if you prefer that). > > In C, pointers are particular types, and you can create pointer > chains that have an arbitrary length. Python don't have pointers. > You always get one level of idirection automatically, and the > referencing and derefencing is handled automatically. If you want > to chain data structures you can easily do that with containers > such as lists, or with classes you define yourself. > > I don't think there are really any controversies concerning values > though. It's the content of the malloced datastructure. It's not > as ovbiously available in Python as in C, but it's still meaningful > to talk about it. > > Then we get to the case of comparision operators in Python, such > as == and > etc. For simple types, they are used to compare the > values/contents of the compared objects in a fairly obvious way. > For containers such as list, Python declares that two lists are > equal if they have the same number of elements, and a pair-wise > comparision of all elements compare equal. E.g. ([a,b] == [c,d]) > == (a==c and b==d). For classes you define, you get to decide > yourself how to implement comparisions. > > This freedom in how to compare things shouldn't really influence > your view on values in Python. Values aren't defined through the > comparision operator. > > One fundamental difference between C and Python is that C is a low > level language where you can directly access and manipulate the > computer memory. Python is a high level language where you can't > to that. You are limited to more abstract operations. I can see > how that makes thing feel more fuzzy. It's a bit like a car with > the hood welded shut. Also, Python is more flexible and customizable. > The comparision operators aren't hardwired to some basic machine > language instructions, their behaviour is defined in your code. It's > like fly-by-wire in modern airplanes. When the pilot pulls a lever, > it doesn't directly cause a rudder to move on a wing, it tells the > steering computer where the plane should go, and the computer decides > what rudders to move, and how much. That doesn't mean that it's > pointless to discuss rudders in modern airplanes.
I welcome what you wrote as you seem to get some understanding of what I am intending to tell. From what you have written I am not 100% sure if you are already there, or you are only close to what I mean, so lets try to clarify it. I am happy to see the term 'content' as it express much better what is stored in an object, because 'content' is a quite general term and therefore it is no problem to say it can be any of value, function, class, operator, type etc. So I see the Python terminology resolved using following hierarchy of terms: - on the top level there is a name called in Python terms _identifier_ being a substitute for a reference to a Python object. - one lever deeper referenced by an identifier is a Python _object_ with all the functionality and data it represent. All this what makes an object i.e. various kind of data stored in it, functions, classes, types, etc. provided is called Python object content, short _content_. - one level deeper, in the object itself they may be various data stored as integer values, strings, etc. . An object can, but need not to hold any data which can be one single _value_ or more of them. The values an object holds can be but need not to be used for exposing them, i.e. some values can be 'hidden' from being present in an object and used only for internal object purposes. Let's summarize providing following rough draft of hierarchy of terms: identifier ->(dereferencing)->object->(is container for)->content->(is a superordinate concept covering one or more of)->value, function, class, type, object, etc. Any comments, refinements, corrections, adjustments? Claudio -- http://mail.python.org/mailman/listinfo/python-list
