Joe Strout wrote: > ru...@yahoo.com wrote: > >>>> a = array (1,2,3) >>>> b = a >>>> a[1] = 4 >>>> print b >>>> >>>> C, C++, VBA, Fortran, Perl: 1, 2, 3 >>>> Python: 1, 4, 3 >>> You are mistaken >> >> I don't think so. >> See http://groups.google.com/group/comp.lang.python/msg/f99d5a0d8f869b96 >> The code I quoted there was tested. >> In the C/C++ case, array-to-pointer coercion confuses >> the issue so I embedded the array in a struct which >> is more like an "object". > > No, that's cheating (IMHO). Structs used directly (rather than via > pointers) are the odd beast, and while they're certainly possible in C, > they are far from the normal idiom. And certainly embedding an array in > a struct just to force it to be copied, avoiding the standard reference > semantics, is an arbitrary trick.
It was intended as a purely rhetorical device to avoid requiring a lot of verbiage to say why a struct example is used for C and arrays for the others and why that makes no difference to my point. Actually, the whole code/results thing was purely for effect since I presume most people reading already understand how assignments work in these languages, or that least that there are significant languages using copy-like assignments. > I never claimed that you *couldn't* have copy semantics in C; you can do > almost anything you want in C (or C++). But the *normal* usage of an > array is via a pointer, in which case the semantics are exactly the same > as in Python, Java, REALbasic, .NET, etc. Arrays are the only datatype in C that don't use copy-like assignment. Everything else does. >>(Keep in mind >> my point was not to show the behavior of arrays, but to >> show that several common languages *do not* use Python's >> "*all* names are references" model -- though of course >> this does not preclude their having some Python-like >> assignments since they all have some way of doing >> references.) > > Ah. OK then, I guess I missed you're point. You're absolutely right; > many languages have both reference types and value types. Python is a > bit unusual in that it has only reference types. I would have picked a > different example to illustrate that, but it's true nonetheless. If one accepts that there are a "lot" of people who post in here that clearly are surprised by Python's assignment semantics, and further appear to expect assignment to have copy-like semantics, then where is that expectation coming from? How would anyone develop that expectation if (from a different post in this thread), "[Python's] idea of assignment is the same as anyone else's." If you maintain that reference-like assignment is very common and something every programmer is accustomed to, then where are they getting the copy-like assignment expectations from? I agree that most of the time, when one is using large (memory) composite "objects", and one needs to pass, or access them by different names, one will often use references to do so in order to avoid expensive copies or to get desired "shared" behavior. But (with the exception of C arrays [*1]), doing so requires some special syntax in all the languages I mentioned (AFAIK). So it still seems to me that this is a likely explanation to why there is frequent misunderstanding of Python's assignments, and why responding to such misunderstandings with, "Python's assignments are the same as other languages'", is at best not helpful. [*1] I have often wished that C handled arrays the same way it does structs. I am sure that the pointer-array pseudo-equivalence seemed like a very clever idea at the time but I wonder if Dennis Richie ever had second thoughts about it. -- http://mail.python.org/mailman/listinfo/python-list