Mailman 3 March 2011 - Edu-sig

xturtle online via processing.js !?
by Jurgis Pralgauskis Sept. 27, 2012

Sept. 27, 2012

Hi, I am struggling around with interactive online py tutorials with https://launchpad.net/projects/intro-to-code (ith might become securely sandboxed soon, as pypy made it possible http://blog.sandbox.lt/en/WSGI%20and%20PyPy%20sandbox :) but one more thing is I'd like to let access xturtle functionality online - one possible way could be triggering tkinter to save its canvas to ps, and then convert them with imagemagic and show via web (animated gif or static) - but if pyjamas can render GUI for js (http://www.google.lt/search?&q=pyjamas+python ), mayby there is a way to **translate turtle commands to processing.js analogues** http://ejohn.org/blog/processingjs/ would it be difficult -- how do you think? -- Jurgis Pralgauskis tel: 8-616 77613; jabber: jurgis(a)akl.lt; skype: dz0rdzas; Don't worry, be happy and make things better ;) http://sagemath.visiems.lt

4 6

re Python's "batteries included" meme
by kirby urner Oct. 10, 2011

Oct. 10, 2011

As I watch students struggle with the: if __name__ == "__main__": concept (where to put it, what it does), it occurs to me we could be doing more to leverage the already well-worn "batteries included." What's different about Python? The rich libraries it comes with, including a cross-platform GUI IDE. That's one meaning of "batteries included". But in another sense we could speak of the generic module as a "battery" with the "if run top-level" logic having to do with battery *testing*. ==== python module ==== [ BATTERIES ] (functions, classes, global-to-module names...) if __name__ == "__main__": [ BATTERY TESTERS ] ==================== That changes the meaning a little more, to where each Python module is like "a battery pack" with its own set of "testers". One thing we do with battery packs is we "import" (promote) their internals within a top-level namespace that starts off in some other (alien) module. Another thing we do with battery packs is run them top-level namespaces on their own, perhaps depending on imports (outsourced resources). I'm not suggesting harping on this too much, just another slide that goes by, but a fun mnemonic, and reinforcing of an already approved / useful design pattern (see my previous post in this edu-sig archive for an example of this self-testing style, relying on doctest for services). Kirby

2 12

PSF Brochure - call for submissions
by Vern Ceder April 19, 2011

April 19, 2011

Hi everyone, In chatting with Charlie Clark and others today, it came up that we aren't doing as much as we might to promote the successes of Python in education. So I agreed to pass along to this list the call for content for the PSF brochure. Please feel free to write up your successes with Python and submit them. They will be considered for inclusion in the brochure as mentioned in the call for submissions below. Cheers, Vern Call for submissions for promotional brochure A new PSF project aims to create professional quality promotional material about Python. The first goal is to create a brochure to showcase the many ways Python is used. It will include use cases to highlight the ways the language allows users to accomplish their tasks both in educational and in professional settings. Project team members Marc-André Lemburg, Jan Ulrich Hasecke, and Armin Stross-Radschinski created this Plone marketing brochure for the German Zope User Group. It is the inspiration for this new project. Community feedback and awareness is vitally important for the success of this initiative, mainly to gather information to be used in the brochure. We are especially looking for interesting projects that can be discussed as use-cases. If you have any suggestions for information to include in the brochure, please contact Marc-André Lemburg or send an email to brochure AT getpython DOT info. UPDATE: more information about the brochure, including a newsletter, can be found here - http://brochure.getpython.info/ -- Vern Ceder vceder(a)gmail.com, vceder(a)dogsinmotion.com The Quick Python Book, 2nd Ed - http://bit.ly/bRsWDW

5 7

Too simple (was Re: Interesting "gotcha")
by Edward Cherlin March 30, 2011

March 30, 2011

Einstein probably did not say, "Everything should be made as simple as possible, but _no simpler_." However, somebody did, and somebody was right. One of the biggest problems in teaching programming is the constant pretense that we are not doing complicated mathematics, and the resulting attempt to hide the math. There is a lovely little book called Mathematics Made Difficult, whose premise is that refusing to tackle topics of modest complexity makes understanding far more difficult. With examples, of course. I have a similar complaint about freshman college physics courses that attempt to get by with no calculus. One of my favorite matth examples is how the use of elementary differential equations and Taylor series simplifies the definition of trigonometry. Define the exponential function by the equation y' = y which says that the growth rate of the function is proportional to its current value. Bring in examples from compound interest, biological growth, inflationary cosmology,... The function we are looking for is exp(x) = sum_0^\infty (x^n)/n! or any multiple of it. If you know that d(x^n)/dx is nx^(n-1), then you can see that the derivative of the power series for exp is itself. Now solve y' = -y (negative of exp) y'' = y (hyperbolic sinh and cosh functions) y'' = -y (sin and cos functions) in the same way, and look at the relations among their power series. Now derive e^(i\pi)+1=0 from e^(i\theta) = cos \theta + i sin \theta, which follows directly from the power series above, and then switch to linear algebra to get the sum, difference, and other formulae, and geometry to get the solutions of triangles. If anybody has difficulty with any of this I can point you to textbooks using these methods. If you would like a bit more of a challenge, we can do this all over again in elliptic and hyperbolic geometry, where we don't have similar triangles. ^_^ On Wed, Mar 30, 2011 at 13:50, Kirby Urner <kurner(a)oreillyschool.com> wrote: > > What is a Python module? #========================== > Common answer is "a file containing Python source code?", > but I'm questioning whether that's sufficient definition. > How about an importable .pyc or .pyd, with no .py in the > picture. That's a module too, no? > ** Import Star #==================================== > When is > import * > a good idea? > There's all this righteous moralistic hoopla that gets built up > against specific idioms, to where eval( ) appears to be fighting > for its very existence... Mary wants to keep her little lambda. > So I'd rather phrase these in the positive, as in when IS it > a good idea... e.g. to use semi-colons between statements. > ** Another student question: #========================= > Why does all([]) return True by default? Is this a case > of half full versus half empty? > ** Correcting a misconception #======================== > No, docstrings do NOT have to be triple quoted. > Kirby > > _______________________________________________ > Edu-sig mailing list > Edu-sig(a)python.org > http://mail.python.org/mailman/listinfo/edu-sig > > -- Edward Mokurai (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) Cherlin Silent Thunder is my name, and Children are my nation. The Cosmos is my dwelling place, the Truth my destination. http://www.earthtreasury.org/

2 1

Interesting "gotcha"
by Michael H. Goldwasser March 30, 2011

March 30, 2011

To start a new thread, I'm always trying to keep a list of some common "gotchas" that beginning students run across when using Python, or things that teachers should keep in mind when teaching with the language. I have in mind commands that do not generate runtime errors, but are likely to lead to logical errors that are not apparent to students, and most of these are legal due to the very flexible nature of the Python language. Some classicss are data.sort # no-op data = data.sort() # bye-bye data result = result.upper # probably not what you expect if answer.isupper: # always true ("but I entered a lowercase answer") This semester, I ran across a new one that took me quite some time to figure out what was happening. This started with a habit that too many students have of wanting to compare boolean values to True/False literals, rather than just using the boolean as a condition. That is, students seem drawn to the syntax if answer.isupper() == True: rather than the preferred if answer.isupper(): These complaints are more of style than substance, as the two versions are logically equivalent. But then a student came to me with code that wasn't behaving. The syntax they used was something akin to if x > y == True: however the condition was not being triggered, even when we verified that x was indeed greater than y. You can try this out with explicit values as follows. >>> if 5 > 4 == True: ... print "Good" >>> You will find that the body is not executed. More directly, you can look at the conditional value directly as >>> 5 > 4 True >>> 5 > 4 == True False This baffled me for an hour before finally seeing what was happening. I'll leave this as a puzzle for readers (many of whom I'm sure will be quicker than I was to see the solution). For those who give up, I offer the following link as a spoiler. http://docs.python.org/reference/expressions.html#comparisons With regard, Michael +----------------------------------------------- | Michael H. Goldwasser, Ph.D. | Associate Professor | Director of Computer Science | Dept. Mathematics and Computer Science | Saint Louis University | 220 North Grand Blvd. | St. Louis, MO 63103-2007 | | Office: Ritter Hall 108 | Email: goldwamh(a)slu.edu | URL: http://cs.slu.edu/~goldwasser | Phone: (314) 977-7039 | Fax: (314) 977-1452

7 7

The Undiscoverable (was Re: Interesting "gotcha")
by Edward Cherlin March 30, 2011

March 30, 2011

I am a big fan of discovery learning, and thus down on anything that interferes with discovery. I practice what I call defensive documentation on such problems, as do some others. See for example, The C Puzzle Book, and my Sugar Labs page http://wiki.sugarlabs.org/go/The_Undiscoverable We will need comprehensive, user-friendly documentation of gotchas in Python and Smalltalk for the Sugar project, for the benefit of teachers and students alike. On Tue, Mar 29, 2011 at 19:09, Carl Cerecke <carl(a)free.org.nz> wrote: > My experience of confusing boolean expressions was the code: > >>>> 1 == 2 in [2, False] > False > > which, when parenthesised the two possible ways >>>> (1 == 2) in [2, False] > True >>>> 1 == (2 in [2, False]) > True > results in sensible values (although the second one's sensibility is > debatable) > > I couldn't figure it out quickly either. In fact, I ended up decompiling to > byte code to figure out what was going on. > > As far as other 'gotcha's in addition to the ones already mentioned: > > Calling a file the same name as a module in the standard library. Import > <name> will get the local file, not the stdlib one, which is confusing if > you wanted the stdlib one. > > I've noticed that students will somtimes put import statements inside a > function - right before they need to use whatever they imported: > def area(r): > import math > return math.pi*r*r > > Cheers, > Carl. > > On 29 March 2011 18:06, Michael H. Goldwasser <goldwamh(a)slu.edu> wrote: >> >> To start a new thread, I'm always trying to keep a list of some common >> "gotchas" that beginning students run across when using Python, or >> things that teachers should keep in mind when teaching with the >> language. I have in mind commands that do not generate runtime errors, >> but are likely to lead to logical errors that are not apparent to >> students, and most of these are legal due to the very flexible nature >> of the Python language. Some classicss are >> >> data.sort # no-op >> >> data = data.sort() # bye-bye data >> >> result = result.upper # probably not what you expect >> >> if answer.isupper: # always true ("but I entered a lowercase >> answer") >> >> >> This semester, I ran across a new one that took me quite some time to >> figure out what was happening. This started with a habit that too >> many students have of wanting to compare boolean values to True/False >> literals, rather than just using the boolean as a condition. That is, >> students seem drawn to the syntax >> >> if answer.isupper() == True: >> >> rather than the preferred >> >> if answer.isupper(): >> >> These complaints are more of style than substance, as the two >> versions are logically equivalent. But then a student came to me >> with code that wasn't behaving. The syntax they used was something >> akin to >> >> >> if x > y == True: >> >> however the condition was not being triggered, even when we verified >> that x was indeed greater than y. You can try this out with explicit >> values as follows. >> >> >>> if 5 > 4 == True: >> ... print "Good" >> >>> >> >> You will find that the body is not executed. More directly, you can >> look at the conditional value directly as >> >> >>> 5 > 4 >> True >> >>> 5 > 4 == True >> False >> >> This baffled me for an hour before finally seeing what was happening. >> I'll leave this as a puzzle for readers (many of whom I'm sure will be >> quicker than I was to see the solution). For those who give up, I >> offer the following link as a spoiler. >> http://docs.python.org/reference/expressions.html#comparisons >> >> With regard, >> Michael >> >> +----------------------------------------------- >> | Michael H. Goldwasser, Ph.D. >> | Associate Professor >> | Director of Computer Science >> | Dept. Mathematics and Computer Science >> | Saint Louis University >> | 220 North Grand Blvd. >> | St. Louis, MO 63103-2007 >> | >> | Office: Ritter Hall 108 >> | Email: goldwamh(a)slu.edu >> | URL: http://cs.slu.edu/~goldwasser >> | Phone: (314) 977-7039 >> | Fax: (314) 977-1452 >> >> _______________________________________________ >> Edu-sig mailing list >> Edu-sig(a)python.org >> http://mail.python.org/mailman/listinfo/edu-sig > > > _______________________________________________ > Edu-sig mailing list > Edu-sig(a)python.org > http://mail.python.org/mailman/listinfo/edu-sig > > -- Edward Mokurai (默雷/धर्ममेघशब्दगर्ज/دھرممیگھشبدگر ج) Cherlin Silent Thunder is my name, and Children are my nation. The Cosmos is my dwelling place, the Truth my destination. http://www.earthtreasury.org/

1 0

looking for explanations... globals dynamic dict
by kirby urner March 29, 2011

March 29, 2011

On Mon, Mar 28, 2011 at 3:23 PM, Michael H. Goldwasser <goldwamh(a)slu.edu>wrote: > > > Note well that the issue has changed since the original post. The > question at the time concerned the following code > > Not to quibble, but the issue of the *original* post had to do with assignments (such as those below) dynamically mutating an "environment dict" named globals(). What this function returns varies moment to moment as a side effect of new assignment operations top level, or deletions. dir(), on the other hand, returns a snapshot, a "static" list (not that lists are static in the sense of immutable -- not what I meant). One could imagine a globals() that *did* return a snapshot, as dict(globals()) does. >>> g = dict(globals()) >>> for k,v in g.items(): print(k,v, sep=":") # no problemo __builtins__:<module 'builtins' (built-in)> __name__:__main__ __doc__:None __package__:None >>> a = 1 > >>> b = a # b and a are two different 1s > > Carl correctly points out that b and a are not two different 1s in > this case. The assignment statment of a = b has the same semantics for > integers as it does for any other data type. a and b become aliases > for the same underlying instance. On any platform, it will be the > case that > > >>> a is b > True > > folowing that assignment. Very true and related to Python's bias against unnecessary copying, making copy (as a verb) live inside its own module (like in a dog house) not even present as a built-in. This is because names are light and airy whereas the objects they name on the heap may be gargantuan, in terms of resources used. green = Giant( ); red = green should not inadvertently cause two instances of Giant, with copying a side effect of assignment. As a language, Python is refreshingly consistent about not doing that. > The original misunderstanding involved the > semantics of b += 2; that command does not mutate the underlying > instance, but re-associates the identifier b to a new value (while a > remains associated with the value 1). > Likewise I get students talking about how "hello world".upper( ) is "transforming" a string, whereas more accurately its returning a new string instance that's based on "hello world" -- like transcribing DNA, building a protein. So is "transcribing" to go back to inadvertent copying? No, because a = "hello world"; b = a.upper( ) is about creating two different strings, each with its own name. No copies here. > > In your reply, the code fragment (below) shows a different issue > regarding the re-use of integer literals in source code (as you > assigned b=1 rather than b=a). In that case, it is system-dependent > whether the interpretter uses different instances or the same > instance, and you are right that there is no guarantee that equivalent > instances will be identical instances. > >>> (17 + 1) is 18 True >>> 8243985209384708709180298734 is (8243985209384708709180298733 + 1) False Implementation details... Kirby > > With regard, > Michael > > > > > Python 2.6.6 > > Type "help", "copyright", "credits" or "license" for more information. > > >>> w = 1 > > >>> y = 1 > > >>> w is y # this might surprise you > > True > > > > [PyPy 1.4.1] > > Type "help", "copyright", "credits" or "license" for more information. > > > > >>>> w = 1 > > >>>> y = 1 > > >>>> w is y # or are you so used to CPython that this surprises you? > > False >

1 0

Re: [Edu-sig] looking for explanations... globals dynamic dict
by Laura Creighton March 29, 2011

March 29, 2011

In a message of Tue, 29 Mar 2011 13:27:20 +1300, Carl Cerecke writes: >Yes. You are right. But so was I (on the second time around): > >a=1 >b=1 > >a and b could refer to the same object or different objects with the same >value. It depends on implementation details. I agree here. > >a=1 >b=a > >a and b refer to the *same* object here regardless of implementation. >Massimo said they were different, because b+= 2 doesn't change a. That >statement is incorrect. > >That's really all I was trying to say. I wasn't trying to be philsophical >about Platonic singleness in the universe or whatever. > >Cheers, >Carl. Ok. I still found the way you said that confusing. Sorry about that. Laura

1 0

Re: [Edu-sig] looking for explanations... globals dynamic dict
by Laura Creighton March 29, 2011

March 29, 2011

In a message of Tue, 29 Mar 2011 11:49:08 +1300, Carl Cerecke writes: >--20cf307abcff67e7bc049f92c049 >Content-Type: text/plain; charset=ISO-8859-1 > >Yes. Laura, you're correct. I'll try again: > >Massimo was trying to say that after: >a = 1 >b = a > >b and a refer to *different* 'one's because changing one of them (b += 2) >doesn't change the other. > >This isn't true. They refer to the same 'one' object (regardless of pytho >n >implementation). b += 2 doesn't change the 'one' object, but simply point >s b >to a 'three' object. > >There. How's that? > >Carl. Incorrect, I think. When I am talking about 'the same 'one' object', what I mean is not some sort of philosophical one-ness, some Platonic ideal of one, which like all the numbers, is a singleton, wherever it occurs in the universe. I mean something much more concrete than that. Somewhere in my computer are addressable pieces of memory, and in those locations are values. When I say that two variables are bound to the same object I mean they refer to that exact same piece of memory right there. (We will ignore, for the purpose of this discussion, issues related to garbage collectors that move objects around. Because its the job of the gc writer to make sure that after the collection happens, all of those references to the old memory location all point to the new memory location. So the location is different, but the property that all variables bound to the same object get the same location in memory remains true.) Consider what happens when your memory goes bad. Stray alpha particle, or (more likely) just a bad bit of memory. I've typed: >>> w = 1 >>> y = 1 >>> z = 1 suddenly, a bit of memory goes bad, the chunk that w is bound to. Instead of containing 1, it contains 2. What happens? Well, in CPython, w is now bound to the value 2. So is y and z. And I will bet that CPython will fall over and die a horrible death. All the places where it internally uses the value '1' will get the wrong value. But this is an implementation detail. But in PyPy, when the chunk that w is bound to goes bad, y and z, which were bound to entirely different pieces of memory, still have good values in them. Assuming that w is not something that PyPy uses internally, it is entirely possible that things could go on seemingly fine. Should w be in the code you typed at an interactive PyPy interpreter, you may be amazed and perplexed when you type: >>>> w = 1 # that memory location goes bad right now! >>>> w + w 4 Not the result you expected. You'd complain pypy was broken, and if it kept happening (i.e. it was a bug, not bad memory) you'd be correct. --------------- What I think you are trying to say is that you cannot change the values of immutable objects. Which is very true. (Barring disasters with bad memory and alpha particles and the like.) But this has nothing to do with how many immutable objects share the same value. It has to do with the fact that you cannot mutate immutable objects. >>>> a = 1 >>>> a = 2 >>>> a = "horseradish" All I have done is changed a's bindings. No walking out to memory, making a chunk of it mean '1', and binding a to it, then walking about again, finding the same bit of memory, and scribbling on it so it means '2', and then walking out and scribbling on it to mean 'horseradish'. That doesn't happen. as opposed to: >>>> a = [1] >>>> b = a >>>> a.append(2) >>>> b [1, 2] a.append(2) really did walk out into memory, find the bit that a was bound to, and scribbled on it so that where it once said [1] it now says [1, 2] Since b is bound to the same bit of memory, it changes too. Laura

3 2

Re: [Edu-sig] looking for explanations... globals dynamic dict
by Laura Creighton March 28, 2011

March 28, 2011

In a message of Tue, 29 Mar 2011 09:59:40 +1300, Carl Cerecke writes: >Well, not really. Although I see what you are trying to say. >numbers (like strings) are immutable. There can ever be only one number 1 >You can't change a number to something else. If add 5 to 3, the number 3 >doesn't change, I get a new number, 8. This is merely an implementation detail. Python 2.6.6 Type "help", "copyright", "credits" or "license" for more information. >>> w = 1 >>> y = 1 >>> w is y # this might surprise you True [PyPy 1.4.1] Type "help", "copyright", "credits" or "license" for more information. >>>> w = 1 >>>> y = 1 >>>> w is y # or are you so used to CPython that this surprises you? False You can have as many number ones as you like. In CPython they are cached to be the same object, but you shouldn't rely on that behaviour. It's actually pretty dodgy to test the object identity on immutable objects -- unless you want to surprise people like I tried to. Incidentally Python 2.6.6 Type "help", "copyright", "credits" or "license" for more information. >>> w = 5234 >>> y = 5324 >>> w is y False so after a certain point, the CPython developers have decided that the performance gains of cacheing all number xs as the same x isn't worth it. Laura

3 2