Re: why cannot assign to function call
Wait a sec... I think I get this... In essence, the implication of immutability for Python is that there is only one "parrot", one "spam,"in fact one anything. (This seems like it must hold for data primitives - does it hold for complex objects as well? It seems it must...) In addition there is only one 1, and one 2 etc. We may or may not have realized that string in a memory address to which variable names can be bound, but should we do so, there is only one "parrot" Python, is in fact, a Platonic programming language. Weird. If I've got this right, worth chewing on On 1/2/09, Derek Martin wrote: > > On Tue, Dec 30, 2008 at 02:21:29PM +, John O'Hagan wrote: > > Fortunately, unlike the murky world of philosophy, Python (AIUI) > > simplifies this question by simply declaring that yes, in the case > > of mutable objects, we may say that we are still referring to the > > same object although we've changed it, and no, in the case of > > immutable objects, we may not, and must exchange it if we want a > > different "value" (a word too fraught with ambiguity in this context > > to use unquoted!). > > That's sort of true; it would seem to be more accurate to say that > whenever a name is assigned to an object and subsequently reassigned, > the name no longer is associated with the original object. In the > case of mutable objects, the object can be changed by performing an > assignment of *part* of the object through its original name, i.e. > strings may be mutable, but the following code still produces two > different objects: > > a = 'hello' > a = 'goodbye' > > The first object so created is orphaned; it's been given the Russian > non-person treatment. It still exists, but the authorities (i.e. the > python interpreter) don't acknowledge it and provide the rest of the > world no way to communicate with it, and eventually it is reaped by > the garbage collector. :) > > 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. And for that matter, it's > pretty unintuitive generally. > > 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 can change what's in > the bin, but the name you gave the bin always points to the same bin. > This tends to be conceptually true even if it might technically not be > true in a given implementation of a language. > > Python is very different from this. Names are not addresses of bins; > they are instead simply ephemeral labels which are given to bins, > where the bin is a Python object which contains specific data at the > time of assignment. A second assignment of that name doesn't change > what's in the original bin; it actually (probably) first creates a new > bin, then removes the name from the original bin and assigns it to > the new one. Intuitively, it's a bit like saying your kitchen table > is no longer a kitchen table, and now the thing where you wash your > dishes is a kitchen table. It doesn't really make a lot of sense > (whether or not it's so for good reason), and it makes describing the > assignment model necessarily convoluted, whereas the "named bins" > model from the majority of other languages people are likely to have > been exposed to is simple and sensible. > > It's small wonder that neophytes try to cram Python behaviors into > terms and computing concepts they already understand from learning > other languages, and that they fail to do so. What's mystifying is > that when Pythonistas reply to their messages, they universally seem > confused at how this could possibly happen, and often enough actually > seem offended (or at least offensive) when it inevitably does happen... > > -- > Derek D. Martin > http://www.pizzashack.org/ > GPG Key ID: 0x81CFE75D > > > -- > http://mail.python.org/mailman/listinfo/python-list > > > -- http://mail.python.org/mailman/listinfo/python-list
Re: why cannot assign to function call
Okay, thanks... Still trying to wrap my fragile little VBA-corrupted brain around names, namespaces, and objects. Progress is being made. For me, the naive idea of variable ==> label for bin has been hard to get past simply because someone in the the back of my head is screaming, "Wait, if the VARIABLE doesn't point to a memory address, (somewhere down the implementation stack) whatinthehell does??" Further reading clarifies: For object X, id(X) is an immutable attribute reference that can ultimately be bound to a memory address (he said, blithely skipping over several layers of architecture...) So, okay, now I can relax. To oversimplify (told you VBA warped my mind) everything in python is an object (at some level). At minimum, all objects have an identity-- id(X), a type which subclasses and extends it from object, and some content, the nature of which depends on the object type. Once I got my head around the idea that there was something that was a fixed point of reference for the object, nevermind what, then I could relax and get on with get on with getting my head around names and namespaces. Thanks for listening to me ramble. On 1/7/09, Steve Holden wrote: > > Dan Esch wrote: > > Wait a sec... > > > > I think I get this... > > > > In essence, the implication of immutability for Python is that there is > > only one "parrot", one "spam,"in fact one anything. (This seems like it > > must hold for data primitives - does it hold for complex objects as > > well? It seems it must...) In addition there is only one 1, and one 2 > > etc. We may or may not have realized that string in a memory address to > > which variable names can be bound, but should we do so, there is only > > one "parrot" > > > > Python, is in fact, a Platonic programming language. Weird. If I've > > got this right, worth chewing on > > > 'Fraid not. Certain immutables are cached by the interpreter, but most > are not. > > >>> s1 = "a" + "b" + "c" > >>> n = 12345 > >>> s2 = "ab" + chr(99) > >>> m = 2469 * 5 > >>> s1 == s2 > True > >>> s1 is s2 > False > >>> n == m > True > >>> n is m > False > >>> id(s1), id(s2), id(n), id(m) > (2146661888, 2146661792, 14453620, 14453584) > >>> > > 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 > -- http://mail.python.org/mailman/listinfo/python-list
Re: why cannot assign to function call
Absolutely. Trivially and at a high level, teaching python to kids who are learning programming as introductory material teaching python to motivated college graduate students teaching python to adult non-professional programmers with a need to learn python (like for instance, frustrated accountants who have HAD IT with VBA...) The difference between the last 2 is important. I am not now nor will I ever be a professional programmer; there's a depth of knowledge to the subject that I will not ever systematically study (mostly due to time constraints). On the other hand, the problems I want and need to solve, I want to get right and will put in the effort to learn what I need to get it right. Contrast the college student. He's getting a broad and hopefully deep grounding in more CS theory than I have. How much does he care? Well, the beer bash Friday at 4 probably has a higher priority in his life right now, not unreasonably. So you can explain things to me fairly technically (I've done lots of VBA programming, hated it, and am motivated in self-study in python), but not too abstractly, because I don't have a deep ground in the theory behind CS and programming. (What I know of grammar parsing comes via some linguistics work I did in college, not Backus-Naur Form, although Noam chomsky was important in both fields) In contrast, the CS student should get a generalized explanation because he needs to grow the skills to work it out on his own, and because the generalized and theoretically grounded explanation is more useful for him in extrapolating to other areas. If he can't do more with it than i can, he needs to change majors. On 1/8/09, Steve Holden wrote: > > Aaron Brady wrote: > > On Jan 8, 1:45 am, Steven D'Aprano > > wrote: > >> On Wed, 07 Jan 2009 10:17:55 +, Mark Wooding wrote: > > snip > >>> The `they're just objects' model is very simple, but gets tied up in > >>> knots explaining things. The `it's all references' model is only a > >>> little more complicated, but explains everything. > >> But it *over* explains, because it implies things that "everybody knows" > >> about references in other languages that aren't true for Python. > >> > >> Of course it's not literally true that "everybody knows" that you can > use > >> references to implement a swap(x, y) procedure. But people coming from a > >> C or Pascal background tend to assume that everything is like C/Pascal, > >> and there are a lot of them. If C was a rare, unfamiliar language, my > >> opposition to using the term "reference" would be a lot milder. Maybe in > >> another five years? > >> > >>> No, indeed. Python is a language for talking about paperweights. And > >>> it's because of the paperweights that the duck-typing works: all the > >>> paperweights are the same shape and size, so they're physically > >>> interchangeable. > >> Okay, the abstraction has leaked again... are the paperweights > references > >> to the objects, or the names we've bound objects to? I'm confused... > >> > >> How do we deal with anonymous objects in your model? > >> > >> -- > >> Steven > > > > Mark, hi, Steven, pleasure as always. > > > > Neither side is perfect or wild; (Do admit it); How do we decide what > > is best for newcomers to Python, depending on background? > > The crux of this mistake is assuming that all beginners are alike, and > that there is therefore a single "best" way to explain things to them. > Teaching should be a dialog, in which the teacher makes use of knowledge > revealed by the student about their existing knowledge and ways of > thinking to present ideas in an easily assimilable form. > > In other words, don't treat all students the same. > > 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 > -- http://mail.python.org/mailman/listinfo/python-list
Work with Open Office
Okay, I'm currently stuck with VBA / Excel in work and the following paradigm: VB (6? .NET? not sure) ==> VBA ==> Excel 2003 and Access Where I'd like to be is this Python ==> X ==> Open Office / (MySQL or other) for some sufficiently useful value of X. Does it exist? Is it just a set of modules I need to be looking for? or something else? -- http://mail.python.org/mailman/listinfo/python-list
Re: Work with Open Office
Have been browsing through this list and reading documentation and tutorials for python self-study. I have, apparently, teh stupid. Google is my friend. Off I go. Thanks. On 1/8/09, Benjamin Kaplan wrote: > > > > On Thu, Jan 8, 2009 at 10:07 AM, Dan Esch wrote: > >> Okay, I'm currently stuck with VBA / Excel in work and the following >> paradigm: >> >> VB (6? .NET? not sure) ==> VBA ==> Excel 2003 and Access >> >> Where I'd like to be is this >> >> Python ==> X ==> Open Office / (MySQL or other) for some sufficiently >> useful value of X. >> >> Does it exist? Is it just a set of modules I need to be looking for? or >> something else? >> >> > > Did you google search first? This is the second result for "Python > OpenOffice". > > http://wiki.services.openoffice.org/wiki/Python > > -- >> http://mail.python.org/mailman/listinfo/python-list >> >> > -- http://mail.python.org/mailman/listinfo/python-list
Learning Python and the Zen of the Mailing List
I decided to learn Python. I decided to learn Python because I hate visual basic for applications and I can feel my brain shrink everytime I invoke that freaking macro editor. It's bad enough that Mwfdg [EMAIL PROTECTED] <[EMAIL PROTECTED]> had to eliminate the original simple keystroke macro tools that were enough for us knuckle-dragging accounting types - oh no! - they had to replace that tool - that we understood - with the most brain dead, useless, overwrought piece of crap abuse of programming language. This forced me to learn how to program. As I learned how to program, I learned that Visual Basic wasn't as bad as I thought - it was far, far, far worse I went to Dartmouth, and, Bill, you harvard dropout, I'd like to inform you that President Kemeny is spinning in his grave for the perversions you have inflicted upon his undergraduate-teaching-tool toy-language. So I write little toy programs and try to wrap my head around real object-oriented programming and and real algorithms and data structures and design my scratch-my-own-itch application in my head while I study. In the mean time, I lurk on this mailing list - I don't have any real questions yet - but reading the questions and answers has been a great way of tapping into the pythonic Zen - I don't know if anyone is a similar situation to me, but I recommend just randomly browsing the mailing list as a means of getting in tune with the rhythm and esthetics of the language Dan -- http://mail.python.org/mailman/listinfo/python-list
