Mailman 3 February 2007 - Edu-sig

Strange transitive import problem
by Peter Drake Feb. 12, 2007

Feb. 12, 2007

The graphics2.py file I supplied earlier (http://www.lclark.edu/ ~drake/courses/cs0/graphics2.py) is a procedural front-end for Zelle's graphics.py. If I run the graphics2.py module, everything works fine, and I can issue commands interactively. A problem happens if I write ANOTHER program, say junk.py: from graphics2 import * print "imported graphics2" background("red") When I run this (within IDLE), it hangs trying to import graphics2. There is no error message or processor load, it just hangs. Can anyone explain (or reproduce) this behavior? Peter Drake Assistant Professor of Computer Science Lewis & Clark College http://www.lclark.edu/~drake/

2 3

Re: [Edu-sig] understanding recursion
by John Posner Feb. 12, 2007

Feb. 12, 2007

Kirby offered Euclid's Algorithm as an example of a recursive function: > def gcd(a,b): > if b: > return gcd(b, a % b) > return a This example *is* wondrous for demonstrating recursion, because it's so elegant and terse. But IMHO, these qualities make it less than ideal for *teaching* recursion. In particular, the terminal case is implied instead of defined: "if b == 0, then return a as the GCD of the original numbers". Here's an implementation that makes more pedagogical sense to me: def gcd(x,y): # terminal case: # smaller goes into larger evenly, or # smaller has been whittled down to 1 if x % y == 0 or y == 1: return y # recursive case: # smaller does not goes into larger evenly # GCD must go into the _remainder_ evenly else: return gcd(y, x % y) Sure, including the "y == 1" case as a separate test might be overdoing it a bit (but it does eliminate one recursion). Another problem (both with Kirby's implementation and mine) is that you "get lucky": if the user specifies the smaller number and the larger number in the "wrong" order, the algorithm magically swaps them for the next recursion. When tackling other recursion problems, students probably won't be able to count on such luck. -John

3 2

Re: [Edu-sig] Populating the lesson plans database: Squeak -> Python
by kirby urner Feb. 12, 2007

Feb. 12, 2007

On 2/11/07, Laura Creighton <lac(a)openend.se> wrote: << snip >> > But again, the problem was that somebody had taught me that something > was _always true_ when the correct statement would be to say that > _this is how we speak of it in this particular language community, > but other communities do it differently_. > > So I'm a firm member of the 'give them as many languages as they > are willing to learn' crowd, at any age. > > my 0.10 euros, > Laura I like your answer Laura. You're in effect reminding students that we have many namespaces (a concept integral to Python), and the very same word *need not* mean the very same thing across namespaces. And thanks to dot notation, we have was to encapsulate and insulate, to counter name collisions. Something *like* dot notation, or dot notation itself, would be welcome in philosophy, is my position on wittgenstein-dialognet, precisely because philosophers are always saying things like "if you don't mean what *I* mean by 'gravity', why not call it 'shmavity' instead?" Computer science offers a more elegant solution. Kirby

1 0

Populating the lesson plans database: Squeak -> Python (reformatted)
by kirby urner Feb. 12, 2007

Feb. 12, 2007

So I'm trying to figure out how much Smalltalk we want to try teaching in the Squeak and eToys units pre Python. My concern is the former may be harder to learn, but some precocious youngsters are going to want to anyway, but then will this make Python "harder" for them, simply because it's "close but different" which could be confusing? I might just be overgeneralizing from my own experience, of living in Italy, picking up some Italian, while taking French in a British then Americanish school, and later Spanish. I found it hard to keep all these Romance languages from fusing in my head. Arabic came later (probably a lost cause in my case). My leaning is towards developing a "Python for Smalltalkers" set of units, which assumes some familiarity with Smalltalk jargon and concepts, such as messages to receivers, complete encapsulation of data, a 'self' keyword, and compares these with Python's, where data is not necessarily so private, and 'self', though used as a placeholder, is *not* a keyword per se (I've seen some Japanese using 'ghost' (smile)). For most middle schoolers, the previous paragraph might read as gibberish, as they're still in Immersion Phase and just like floating around in a fish tank or whatever Alice in Wonderland dream world, interacting with the many exhibits, learning Physics or whatever. They're not yet into the cold hard world of 100% lexical coding where "left brain" is king (just kidding about the king part). But those few who are, like their adult counterparts, might appreciate the bridge literature (screencasts included). Such a literature already exists bridging Python and Scheme for example, down to a Scheme interpreter written in Python (wasn't that Danny Yoo's project?), plus discussions of Scheme's hyper powerful lambda, versus Python's "little lambda" (as in "Mary had a"), not intended for much more than an anonymous inline expression (name your anonymous function Anon if you want it longer?). And of course Python for C programmers was more the original context of the language in the first place (Guido's target demographic was never "children" per se) -- that literature is pretty much complete. Perl coders tend to see Python as a dialect (so similar, yet alien enough to still be considered "a different language"), while Java coders tend to see it as their possible salvation, from a lot of mindless overhead (Bruce Eckel in this category**). But I'm taking my cues from the many Logo -> Squeak -> Python cave paintings I've been exposed to, a well documented sequence, complete with lesson plans database, for ages 8 to 18. So it's the Logo (which Logo?) -> Squeak and Squeak -> Python bridges which most interest me, in terms of collecting citations and/or developing new content. My impression is there're still lots of holes in the Squeak -> Python literature, ready to be filled with new lesson plan filings. Kirby ** http://www.mindview.net/Books/Python/ThinkingInPython.html

1 0

Populating the lesson plans database: Squeak -> Python
by kirby urner Feb. 12, 2007

Feb. 12, 2007

So I'm trying to figure out how much Smalltalk we want to try teaching in the Squeak and eToys units pre Python. My concern is the former may be harder to learn, but some precocious youngsters are going to want to anyway, but then will this make Python "harder" for them, simply because it's "close but different" which could be confusing? I might just be overgeneralizing from my own experience, of living in Italy, picking up some Italian, while taking French in a British then Americanish school, and later Spanish. I found it hard to keep all these Romance languages from fusing in my head. Arabic came later (probably a lost cause in my case). My leaning is towards developing a "Python for Smalltalkers" set of units, which assumes some familiarity with Smalltalk jargon and concepts, such as messages to receivers, complete encapsulation of data, a 'self' keyword, and compares these with Python's, where data is not necessarily so private, and 'self', though used as a placeholder, is *not* a keyword per se (I've seen some Japanese using 'ghost' (smile)). For most middle schoolers, the previous paragraph might read as gibberish, as they're still in Immersion Phase and just like floating around in a fish tank or whatever Alice in Wonderland dream world, interacting with the many exhibits, learning Physics or whatever. They're not yet into the cold hard world of 100% lexical coding where "left brain" is king (just kidding about the king part). But those few who are, like their adult counterparts, might appreciate the bridge literature (screencasts included). Such a literature already exists bridging Python and Scheme for example, down to a Scheme interpreter written in Python (wasn't that Danny Yoo's project?), plus discussions of Scheme's hyper powerful lambda, versus Python's "little lambda" (as in "Mary had a"), not intended for much more than an anonymous inline expression (name your anonymous function Anon if you want it longer?). And of course Python for C programmers was more the original context of the language in the first place (Guido's target demographic was never "children" per se) -- that literature is pretty much complete. Perl coders tend to see Python as a dialect (so similar, yet alien enough to still be considered "a different language"), while Java coders tend to see it as their possible salvation, from a lot of mindless overhead (Bruce Eckel in this category**). But I'm taking my cues from the many Logo -> Squeak -> Python cave paintings I've been exposed to, a well documented sequence, complete with lesson plans database, for ages 8 to 18. So it's the Logo (which Logo?) -> Squeak and Squeak -> Python bridges which most interest me, in terms of collecting citations and/or developing new content. My impression is there're still lots of holes in the Squeak -> Python literature, ready to be filled with new lesson plan filings. Kirby ** http://www.mindview.net/Books/Python/ThinkingInPython.html).

1 0

Re: [Edu-sig] understanding recursion
by John Posner Feb. 10, 2007

Feb. 10, 2007

Andy Judkis <ajudkis(a)verizon.net> wrote: > ... I've found that many kids seem to have a natural ability > to use recursion, but they don't realize that they're doing it, and > they don't understand the implications. > > ... > > def play_game(): > . . . > resp = raw_input("Play again?") > if resp == "yes": > play_game() > My guess, Andy, is that many of the students are not thinking clearly enough to understand the difference between REPETITION and RECURSION. They haven't thoroughly learned the flow-of-control aspect of functions/subroutines. That's not surprising: in real life, kids don't have to formally declare one activity to be finished before they "go to" (heh heh) another activity. IMHO, the kids' first attempt at coding provides an excellent opportunity for you to gently move them from the realm of almost-right "fuzzy" thinking to "crisp" formal algorithmic thinking. > ... My expectation was that they'd write a loop like this: > > while True: > play_game() > resp = raw_input("Play again?") > if resp == "no": > break > Another guess: not many kids will hit upon the "while True ... break" coding scheme on their own. I'd be inclined to let them use this imperfect solution at first: for i in range(1000000): play_game() ... Then you can point out the limitations, inefficiencies, lack of elegance of this solution -- e.g. to quit the game, you have to type Ctrl-C or close the window. Best, John

3 2

For classroom use...
by kirby urner Feb. 9, 2007

Feb. 9, 2007

Here's some field tested code that I think showcases what a student interested in computer graphics might eyeball and run, after some background in the basic syntax. True, there's stuff going on behind the scenes (another module, plus VPython, all well documented). I'll plan to use this with my high schoolers in April. I want them to see what real Python really looks like, to get ideas from, for doing graphics of their own. We also use VRML, maybe just projected on the big screen in front. Kirby """ coupler.py by K. Urner, (gpl) 2007 4dsolutions.net Documentation for Coupler: The Coupler is a space-filling irregular octahedron defined by three mutually orthogonal quadrilaterals: one square and two congruent rhombi. This module constructs these quadri- laterals and displays them in VPython. In the concentric hierarchy, the Coupler's volume = 1 (i.e. is same as tetrahedron's defined by 4 unit-radius CCP balls). http://www.rwgrayprojects.com/synergetics/s09/figs/f86431.html URL for stickworks.py: http://www.4dsolutions.net/ocn/python/stickworks.py Documentation for stickworks.py: http://www.4dsolutions.net/ocn/stickworks.html Relevant VRML worlds by sw dharmraj (see Synergeo on Yahoo!): http://members.westnet.com.au/dharmraj/vrml/coupler.wrl http://members.westnet.com.au/dharmraj/vrml/KmiteCube.wrl See also: Richard Hawkins Digital Archive: http://www.newciv.org/Synergetic_Geometry/ """ from stickworks import Vector, Edge, axes from math import sqrt sqrt2 = sqrt(2) apexd = sqrt2/2.0 # convention nx for -x (negative x) x = Vector((1,0,0)) y = Vector((0,1,0)) nx = Vector((-1,0,0)) ny = Vector((0, -1, 0)) apex = Vector((0, 0, apexd)) napex = Vector((0, 0, -apexd)) class Square (object) : """ Coupler Square Equator in XY plane """ def __init__(self): Edge.color = (1,0,0) self.edges = [Edge(x,y), Edge(y,nx), Edge(nx,ny), Edge(ny,x)] def draw(self): for e in self.edges: e.draw() class Fx (object) : """ Coupler Equator in XZ plane """ def __init__(self): Edge.color = (0,1,0) self.edges = [ Edge(x, apex), Edge(apex, nx), Edge(nx, napex), Edge(napex, x)] def draw(self): for e in self.edges: e.draw() class Fy (object) : """ Coupler Equator in YZ plane """ def __init__(self): self.edges = [ Edge(y, apex), Edge(apex, ny), Edge(ny, napex), Edge(napex, y)] def draw(self): for e in self.edges: e.draw() def test(): """ Draw a Coupler centered at (0,0,0) with XYZ Axes """ # blue axes, please Edge.color = (0,0,1) axes(2,2,2) # create equator objects ofy = Fy() ofx = Fx() osq = Square() # draw the rhombi Edge.color = (0,1,0) ofy.draw() ofx.draw() # draw the square Edge.color = (1,0,0) osq.draw() if __name__ == '__main__': test()

2 4

PyCon edu-py activities Saturday
by Michael Tobis Feb. 9, 2007

Feb. 9, 2007

I have contacted the open space coordinator regarding space for Satruday evening. I am at present inclined to back off presenting a newby lecture for logistic reasons. This should have been planned earlier to fit in with other activities and properly promoted. Rather I'd like to quickly present my approach to the group at our open space session. Please pitch in to improve the content of http://us.pycon.org/TX2007/PyEduto soften us up for whatever point of view you bring to the discussion and to attract more participants. best regards to all Michael Tobis

2 4

understanding recursion. . .
by Andy Judkis Feb. 8, 2007

Feb. 8, 2007

I teach a "serious computer literacy" course to 10th graders. The course covers some things about how hardware works, how the internet works, what operating systems do, etc. The last part is a 3-4 week intro to Python programming. I've encountered some interesting student behavior and I'm curious to know how those of you who are better and more experienced teachers would suggest handling it. Specifically, I've found that many kids seem to have a natural ability to use recursion, but they don't realize that they're doing it, and they don't understand the implications. Case in point: I give them a trivial "guess the random number" game and they add trivial features to it that require some basic programming concepts. One of the features is to have the program ask the user if he/she wants to play again. My expectation was that they'd write a loop like this: while True: play_game() resp = raw_input("Play again?") if resp == "no": break Instead, what many of them do is to put the logic inside the play_game() routine: def play_game(): . . . . . . resp = raw_input("Play again?") if resp == "yes": play_game() As far as they can tell, this works fine. When I look back on my own experiences, it took me a long time to think recursively, and it would never have occurred to me to code it the way they do. I envy them their natural (if imperfect) grasp of the approach. But they don't have any clue that there's a call stack involved, or that someday this could get them in trouble. I shudder to think about the blank looks that I will get if I try to explain why it could be a problem. So far, I've handled it by pointing out "that's recursion, you can do that but there's a little more to it and if you're interested, ask me or look into it further on your own." I guess that lets me off the hook but it doesn't feel quite right. Other options I can think of are: 1) try to explain it and lose most of the class 2) just say "I don't allow it, I have a good reason, let me know if you want an explanation" Neither of these feels quite right, either. These are bright kids but they have great difficulty understanding things like function parameters and return values, and I really think recursion is beyond them at this point. Anybody have any suggestions or similar experiences? Thanks, Andy Judkis Academy of Allied Health and Science Neptune, NJ

7 6

Re: [Edu-sig] Using objects early was Procedural front end
by Andy Judkis Feb. 8, 2007

Feb. 8, 2007

Kirby, in recent posts you made two claims: >That was a paradigm shift as well and part >of a longer story that, in my experience, students enjoy hearing, find >edifying. and: >I have aimed to show there are easy ways to introduce OOP early, using >Python syntax as a guide, that don't require great feats of mental effort >on the part of students. My Dog and Monkey show is quite accessible >to average 8th graders in public school as I've proved in the field. and I was wondering if you would be willing to support them. How do you assess whether or not your students comprehend the material at a level that you consider satisfactory? Anything formal, or just your feeling? What proportion of your kids need to get it for you to be satisfied? The reason I ask is because my 10th graders are well above average but it's quite clear to me that there's -no way- that they can get the material you describe in the time period you are talking about in any useful way. Thanks, Andy

1 0