On Fri, 17 Oct 2008 15:39:33 -0600, Joe Strout wrote: > On Oct 17, 2008, at 3:19 PM, Grant Edwards wrote: > >>> And my real point is that this is exactly the same as in every other >>> modern language. >> >> No, it isn't. In many other languages (C, Pascal, etc.), a "variable" >> is commonly thought of as a fixed location in memory into which one can >> put values. Those values may be references to objects. > > Right, though not in languages like C and Pascal that don't HAVE the > notion of objects. We really ought to stop bringing up those dinosaurs > and instead compare Python to any modern OOP language.
You really should stop assuming that languages still in use are "dinosaurs". There are many, many people whose understanding of such terms as "call by value" or "variable" are based on C or Pascal or even Fortran. Besides, while the Pascal language itself doesn't have objects, plenty of Pascal implementations do. >> In Python, that's not how it works. There is no >> "location in memory" that corresponds to a variable with a particular >> name the way there is in C or Pascal or Fortran or many other >> languages. > > No? Is there any way to prove that, without delving into the Python > source itself? >>> x = 1 >>> id(x) # a unique identifier, in CPython equal to its address 135536432 >>> x = 2 >>> id(x) 135536420 Notice that the address of x changes. Actually, that's a lie. The name 'x' doesn't have an address, except in the sense that the string 'x' must occur somewhere in memory. But that's an unimportant implementation detail. In reality, what we see is: the object 1 is bound to the name 'x'; we ask for the id() of the object bound to 'x' (1), which is 135536432; the object 2 is bound to the name 'x'; we ask for the id() of the object bound to 'x' (2), which is 135536420. That's what is happening at the Python level of code. Anything else is just implementation details. > If not, then I think you're talking about an internal implementation > detail. Namespaces aren't an internal implementation detail, they are fundamental to how Python works. >> All that exists in Python is a name->object mapping. > > And what does that name->object mapping consist of? At some level, > there has to be a memory location that stores the reference to the > object, right? Who cares? That's the *wrong* level. At *some* level, everything is just flipping electrons from one state to another, but I think even you would object if I claimed that: "All computer languages are call-by-flipping-electrons, with no exceptions." Somebody could implement a Python interpreter using literal post-it notes for names and literal boxes for objects. The fact that our CPUs are optimized for flipping bits instead of (say) water flowing through tubes, or clockwork, or punching holes in paper tape, is irrelevant. When discussing what Python code does, the right level is to discuss the Python virtual machine, not the implementation of that VM. If you want to discuss the deeper levels, it's perfectly acceptable to say that the CPython implementation uses memory locations holding pointers. But that's not *Python*, that's hidden detail that the Python programmer can't reach. >>> Nothing unusual here at all (except that some of us here seem to want >>> to make up new terminology for standard behavior, perhaps in order to >>> make Python seem more exotic). >> >> That's because it is fundamentally different from what happens in >> languages like C. > > What happens in a modern OOP language is just as fundamentally different > (which is to say, not really very much) from what happens in C or > FORTRAN or COBOL, too. Which is why modern OOP languages like Python shouldn't use the same terminology invented to describe what Fortran and Pascal do. > If you make up new terms like "rebinds," This is not something that is just "made up", it is an actual description of what the Python VM does. > well, I guess at least that > avoids giving the listener the wrong idea. As opposed to call-by-value, call-by-reference, and "call-by-value-where- the-value-is-the-reference", all of which do give the listener the wrong idea. > Instead it gives them no > idea at all, which may be better, but not as good as giving them the > right idea. But it is the right idea. They just don't know what it means, because they've been listening to people like you who insist on using Pascal terminology with a definition unrecognizable to Pascal programmers. To an ex-Pascal programmer like myself, when you talk about "call by value where the value is a reference", it sounds to me as if you are insisting that cars are ACTUALLY horse and buggies, where the horse is the engine, why are we inventing new terms like 'automobile', that just confuses people. > It still leaves them to investigate what actually happens, > and ultimately they will find that the parameters are always passed by > value in Python. But they aren't. When you call a function, the arguments are not copied before being passed to the function. > May as well save them the trouble and point that out > up front. Well, sure, if you want to be misleading and confusing. > And how many recovering FORTRAN or C programmers do we get around here, > anyway? Enough. It's not just people who have programmed Pascal, but those whose understanding of CBV and CBR have been shaped by ancient half-remembered Pascal lessons. > Java is what they've been teaching in school for the last > several years, and it was C++ for a good decade before that. Have they really? Which school is that? My company has hired a part-time young gun programmer. He's still at Uni, doing Comp Sci, and has *far* wider IT experience than the average programmer his age. His skills? PHP, Perl, C, oh and he's just starting to learn C++ this semester. There are plenty of programmers who have never been to university or collage, and even some who have never learnt programming in school at all. Believe it or not, it's not compulsory. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
