Derek Martin wrote: > On Sat, Jan 03, 2009 at 10:15:51AM +0000, Marc 'BlackJack' Rintsch wrote: >> On Fri, 02 Jan 2009 04:39:15 -0600, Derek Martin wrote: >> >>> On Tue, Dec 30, 2008 at 02:21:29PM +0000, John O'Hagan wrote: >>> What the Python community often overlooks, when this discussion again >>> rears its ugly head (as it seems to every other hour or so), is that its >>> assignment model is BIZARRE, as in it's conceptually different from >>> virtually all other languages substantially taught in undergraduate >>> computer science programs. >> What's the difference between Python and Java or C# here!? Or are they >> also "BIZARRE"!? > > I am happily ignorant of C#. As for Java, take the following code: > > a = 6; > a = 5; > > In Python, when you execute the equivalent code, it causes two > different objects to spring into existence, the first of which may be > cleaned up by the GC (except that since we're using small integers, > that's not likely to happen). Unless I'm misinformed (which is very > possible, my experience with Java has been extremely limited) in Java > that's not the case... the storage is allocated to the name a when > you execute its declaration, and the *same storage* is reused upon > subsequent assignment. > > That behaves exactly like named bins. > Ah, but if the right-hand-side expressions had been Integers rather than integers, things would have been different, no? The point is that once values become complex types it's convenient not to copy them each time they are required. but I needn't flog this particular dead horse as you clearly do understand Python's assignment semantics.
>>> And for that matter, it's pretty unintuitive generally. >> Names and objects are quite "natural" IMHO. There are many real world >> objects which we attach one or more names to, or refer to in sequences >> like "please give me the third book on that shelve" (``shelve[2]``). > > Indeed, but the way we assign names to them does not behave as it does > in Python. Nor does Python's assignment work like it does in algebra, > or anywhere else the Python student is particularly likely to have > seen variable assignment before encountering it in Python. Let's > define intuitive, shall we? From dictionary.com (choosing the > definition which most easily makes my point): > Algebra contains no assignments. > intuitive: adj. capable of being perceived or known by intuition. > > I'm going to go out on a limb and assert that there's NO POSSIBLE WAY > a student could intuit Python's variable assignment behavior, having > never been exposed to that same behavior prior. It needs to be > taught. > As does assignment of any kind. You can't argue that one semantic or another is more intuitive without offering evidence. >>> That is, in what I'll call "normal" computer languages, a variable name >>> is thought of as the address of a bin where some data is stored, and the >>> name is inexorably tied to that bin. >> You just call that "normal" or "intuitive" because that's what you >> learned first. > > In a sense, yes... but isn't that what intuition really is? You can > figure something out whithout being told how it works... That's > either because it's immediately obvious from observing it, or it > behaves like something you've seen before. That is what intitive is. > >> I think the "bin model" is more complex because you don't just have a >> name and an object but always that indirection of the "bin". > > I cheerfully disagree. :) "Named bins" is essentially how algebra > works, and how several generations of computer languages, not to > mention the actual machine language those generated, behaved, before > the current crop. Those interpretations came first, because, much as > in the evolution of any other science, that was the model which was > most intuitive or easily explained. > You're perhaps familiar with some algebra that I didn't study. In algebra and number theory identity and equality are equivalent. This is far from the case in programming languages, so any analogy based on it is specious to some degree. Programming isn't mathematics (except perhaps for functional programming). > But you need not take my word for it. Simply read the archives and > see for yourself how much confusion this has caused on this list. > [Please include the closely related behavior of parameter passing in > your search.] > It's difficult to think of a single aspect of Python that doesn't cause confusion in a typical year. The confusion is sometimes caused by ill-informed comment. While well-informed, you appear to feel that everyone else should share your idea of what's intuitive and what's BIZARRE. Before extending this thread too long please ruminate on the recent parameter-passing thread, of which you are clearly aware. Let's try and create light rather than heat. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ -- http://mail.python.org/mailman/listinfo/python-list
