why cannot assign to function call
joe at strout.net
Sat Jan 10 01:11:12 CET 2009
Mark Wooding wrote:
> As an aside, I don't notice anywhere near as much confusion in Lisp and
> Scheme groups, which might be surprising since Lisp and Scheme have
> precisely the same data model, argument passing convention, and
> assignment semantics, as Python has.
Nor is there anywhere near as much confusion in the REALbasic community
(with which I'm most familiar), which also has the same semantics for
reference types (which in RB is everything except numbers, colors, and
Apparently there is occasionally a little confusion in the Java
community, but it rarely reaches the sillyness proportions seen here:
> * The Lisp and Scheme communities are smaller. This is certainly
> true. But it wouldn't explain what appears to be a disproportionate
> level of confusion on the topic among Python beginners.
> * Individuals in the Lisp and Scheme communities are cleverer and/or
> more widely experienced. One might make an argument that this is
> true and a result of the relative community sizes -- basically a
> result of self-selection. But instead I'll reject this as an
> explanation. It's arrogant and unproven.
> * The Lisp and Scheme communities make a concerted effort to explain
> their data model clearly and precisely. They accept that it's
> actually quite complicated and, rather than pretend that it isn't,
> explain the complexity and the benefits it brings that make the
> complexity worthwhile. I think this is the likely one.
That's a nice way of putting it. I might go a step further and say that
there is a small but vocal portion of the Python community that insists
on confounding the issue by claiming that Python's assignment and
parameter-passing conventions are different from other languages.
(Which, of course, requires one's head to be firmly in the sand with
regard to the basic fact that Python variables contain references, not
> But it's not just assignment that deals with references. It's argument
> passing and storage of compound data as well. (See PLR 3.1.)
> They expect that assignment copies stuff, because that's what assignment
> does. Everywhere that I can think of -- except C++, which leaves
> assignment semantics in hands of the programmer. What they're confused
> about is what, precisely, it is that gets copied. And that, really, is
> a result of an inadequate understanding of the data model.
I have nothing to add to this. It just seem well worth quoting. :)
>> 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).
> Ummm... you mentioned C, C++, `Python, Java, REALbasic, .NET'.
No, actually, that was me. rurpy's list was something like C, FORTRAN,
Perl, and VBA.
> Well, C we've dealt with. C++ is weird. Python we all know, and is the
> main subject of the argument. REALbasic I don't know at all, but BASICs
> traditionally represent data fairly directly (rather than via
> references) so will largely be like C.
Not REALbasic. It's a very modern language with semantics pretty much
identical to Java. Simple types (numbers, colors, Booleans) are stored
directly; all other types (including strings, objects, and arrays) are
stored on the heap and accessed via references.
> .NET isn't a language at all:
> rather, it's a virtual machine, runtime system, class library and family
> of languages each of which may have idiosyncratic semantics.
But they don't, AFAIK -- they all have the same semantics; only the
surface syntax differs. And those semantics are the same as REALbasic
See <http://www.strout.net/info/coding/valref/> for some side-by-side
> Which leaves Java. Java divides the world into `primitive' and
> `reference' types (4.1). The former are represented directly; the
> latter have a pointer to the true data as immediate representation.
Right -- a very common pattern among modern languages.
>> 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.
> That's why I'm not just saying that assignment is the same. I'm also
> saying that the data model is most definitely not the same as C.
Technically true, in that pointers in C require some special syntax, but
the common idiom is to hide this away by defining a new type:
typedef Foo* FooPtr;
Now, for any code using the "FooPtr" type, the data model is the same as
Python (or as Java, RB, .NET, etc., again for code that's using only
More information about the Python-list