On Tue, May 13, 2008 at 2:10 PM, Christopher Thoday <[EMAIL PROTECTED]> wrote: > > Would it not be better to describe the differences between C and Python > variables directly rather than using an analogy? >
Sometimes pure analogies are better though because if you talk too literally in terms of computer memory then what you're giving are implementation details, not necessarily useful heuristics. It so happens that C is very much about computer memory (even conceptually), which tends to erode this distinction. That's why it's considered a low level language, Python a high one -- not a moral distinction about better vs. worse, but a technical one about how close to the metal (conceptually). > In C, a variable is the address of a storage location that contains its > value. If that value is itself an address then the variable is described as > a pointer. > > In Python, a variable is a reference to an object that has a type as well > as a value. In C, the conceptual model includes this "wall of memory bricks" (each brick with an address) that contain data but no awareness of type. Raw content is all crammed into these bricks as tightly as feasible (holes unavoidable sometimes). You can decode the same data as a different type simply by reading it with a different type of pointer. When you advance a pointer to a struct, C skips by the right number of bytes thanks to the type awareness originally provided by struct declarations in source code. > > The statement: > > a= b = c; > > results in three separate values in C but only one in Python. The effect > is the same in both languages provided that c refers to a constant. However, > if c is a mutable object, such as a list, then changing the value of one > variable changes them all. Anyone coming to Python from C may be confused by > this as it is not clearly described in any of the books on Python that I > have read. Python names have a many-to-one relationship to objects. You can go x = y = z = 8; del y; and still have x and z in the namespace, both referencing the 8 object. The fact of 8 being immutable shouldn't be allowed to confuse the picture of a many-to-one relationship. Going y = 10 is merely rebinding the name y to a different object, leaving the others alone. C has this same many-to-one capability with respect to its pointers, which may be passed by assignment. http://cslibrary.stanford.edu/106/ > When passing an argument to a function, C uses pass-by-value whereas Python > uses what is in effect pass-by-reference. In order to obtain > pass-by-reference in C the value must be a pointer. Inside the function the > pointer must be dereferenced by prefixing it with an asterisk to obtain the > value. > > Eur Ing Christopher Thoday > Software Engineer I'd say that in C, type awareness stays with the variables, as the data bricks know nothing of type, yet the pointers know what they point to, how many bytes to advance, or to read when dereferenced. Struct variables also support -> notation, prototypical of dot notation (historically, structs and struct notation were the basis of the first object oriented implementation of C, i.e. C++). You could tell C programmers "everything is a struct in Python, except structs may include functions, access their own data etc." Then say "all variables are pointers to structs". But you have to be careful to explain this is just an analogy, not a literal fact about implementation (obviously). In Python, type awareness resides with the objects, with namespaces being dictionaries of name:object pairs (many-to one). There's no concept of "dumb data" (even 8 is an object) or addressing bricks per se, although we can get integer ids for our objects as in id(y). You can't do much with that id though, except figure out if another name has the same one (the purpose of "is"). Names are little more than Unicode string literals with top-level significance, each paired with an object in a dictionary (the namespace). So in C, intelligence about type remains with the variables (we might say), whereas in Python it remains with the objects, which are quite introspective. Kirby _______________________________________________ Edu-sig mailing list [email protected] http://mail.python.org/mailman/listinfo/edu-sig
