Mailman 3 December 2003 - Edu-sig

re: Draft of a funding request
by Arthur 15 Dec '03

15 Dec '03

Michael writes - >Perhaps this is a somewhat odd thought, but Python does such a good job of >smoothing over the rough edges of many parts of computer science, it isn't >entirely unbelievable that it can also become a common thread for >education, at least in the context of the use of computers in education. That's sort of my theory. Python's strength is not in going head to head with whatever is the current leading language for advanced placement exams in computer science. Some of the reasons are obvious. Careerist type reasons. OTOH, Python is used successfully time and again in situations where the introduction to programming is tightly integrated with other curricula goals not directly related to core computer science. Bioinformatics, physics, statistics, etc and etc. I don't know that computer programming with Python is for everybody, but I certainly do think it is for folks whose core interests are outside the direct realm of computer science. And since I think this is where Python is most unique, it is also where its competitive advantage in seeking funding would naturally lie. Not that you are arguing with me. Its just wording. The last line of your most recent post still focusing on Python as a "first language". For me, just for example, Python is probably a last language as well as first. It gets me from here to there for pursuit of interests that are on one hand academic, and on the other, not directly focused on computer science. And all I want to do is get from here to there. And I think my use and interest in Python as an academic tool is typical of the kind of interest it generates in academia. And in laboratories, for example. To me, this is why Python deserves and gets the $2 mil. Art

5 6

Re: [Edu-sig] re: Education Arcade
by Laura Creighton 15 Dec '03

15 Dec '03

In a message of Sat, 13 Dec 2003 12:26:44 PST, "Kirby Urner" writes: >Imagine an arcade game wherein you're running for president of some country. >You have money concerns, issue concerns, perception concerns. Donor X >promises you big bucks, but not if you appear to side with Y in your >statements. Different versions of a stump speech appear on screen. You >have to decide which one you'll go with (advisors weigh in with pros and >cons, perhaps audibly, using emotional language). Money sources appear or >dry up as a result of your choices. In the meantime, your competition is >doing likewise. Negative ads appear, about your accepting funds from >Donor X. > Kirby, this is an example of the problem. When you teach children using a simulation, you teach them, in addition to everything else, to think within the system that the simulators were using. So here we have, as unchallenged assumption -- it costs big bucks to become president. The fix for that would be to pass campaign finance reform -- forbid spending beyond a certain amount. Every version of those stump speeches come with the biases of the people who authored them. Their results have the outcomes that somebody programmed in as well. You have now taught the children how to use emotional language to criticise people and get them to change their positions based on how well you can manipulate them. Your funding base, presumably, is either the White, Prosperous Middle class, or Big Business -- since you are campaign contribution based. Does your simulation reflect the fact that poor people do not vote in the USA? Negative ads are now a fact of life .... it goes on, and on. I don't want another generation of Americans conditioned to view the system as something that can not be changed, but can only be worked. I don't know what the best way to teach children how to question authority, recongnise opportunities, and strive to improve the society they are in, but I suspect that this is a step in precisely the wrong direction. Laura

5 4

re: Python Programming: An Introduction to Computer Science
by Toby Donaldson 15 Dec '03

15 Dec '03

-- Dr. Toby Donaldson Assistant Professor School of Interactive Arts and Technology Simon Fraser University > -----Original Message----- > From: edu-sig-bounces(a)python.org [mailto:edu-sig-bounces@python.org] On > Behalf Of edu-sig-request(a)python.org > Sent: December 13, 2003 8:54 AM > To: edu-sig(a)python.org > Subject: Edu-sig Digest, Vol 5, Issue 11 > > Send Edu-sig mailing list submissions to > edu-sig(a)python.org > Message: 1 > Date: Fri, 12 Dec 2003 11:00:29 -0800 > From: "Kirby Urner" <urnerk(a)qwest.net> > Subject: [Edu-sig] Re: Python Programming: An Introduction to Computer > Science > To: edu-sig(a)python.org > Message-ID: <E1AUsWf-0003Kt-Me(a)mail.python.org> > Content-Type: text/plain; charset="US-ASCII" > > > I'm reading John Zelle's book, a real CS1 text book with exercises, using > Python as the language. > > This is an exciting book (see my concluding remarks below). I agree with > the blurbs on the back. E.g. Russell May of Morehead State University > writes "This text does an excellent job of filling a gaping hole in the > Python community -- a textbook for an introductory computer science > class... > It is as good a text as I have read for CS1." > > Zelle has a lot of experience teaching CS1, back to Pascal days. I trust > his sense of what belongs in a CS1 course in your average community or > 4-year college. It's a fairly gentle slope by design, and Python makes it > gentler. > > What frustrates me somewhat is that CS1 doesn't really show off the full > power of Python, and by the time we get to CS2 at Zelle's academy (and I'm > suspecting this will be somewhat typical), we're on to Java. The > reasoning > is solid: real CS majors need exposure to a static-typed language, as > well > as to more than one language. I have no problem with this reasoning. > > The frustrating part is this means cool CS2-level features of Python may > not > get much if any airplay. Syntax overloading is not taken up, and many OO > concepts get only initial treatment (e.g. no discussion of class vs. > instance properties/methods, nor of multiple inheritance). No list > comprehensions, generators, regular expressions. No passing of functions > as > parameters to other functions. No numarray, nor much use of the standard > library beyond math, random, string and Tkinter (which last is wrapped in > a > simpler module, graphics.py). No default or optional parameters. > > Try-except *is* covered, as is eval() and docstrings. > > Again, I'm not questioning Zelle's judgment re what's appropriate to CS1. > He has long experience in this domain. He's fully aware of what Python > can > do, and just had to make these necessary cuts. It's probably somewhat > painful to him as well, as when James Cameron (movie director) had to cut > out reel three of 'Aliens' in order to have it fit the movie-house time > constraints of the day (reel three is restored in the extended play > version). > > So let's assume a future in which Python is wildly successful as a CS1 > language, but with this pattern of moving on for CS2, with the sense that > Python has well-prepared students to tackle something thornier. Given > this > bright future, I still have this lingering concern that Python may > eventually be typecast as a "beginner language" in the sense of being not > sophisticated enough for higher level development. > > As Guido concludes in his short forward: "Reader of this book, > congratulations! You will be well rewarded for studying Python. I > promise > you'll have fun along the way, and I hope you won't forget your first > language once you have become a proficient software developer." > > I think it's this hope that I'm echoing as a concern. How will we ensure > that Python continues to receive attention even *beyond* its considerable > virtues as a beginner's language? > > When I try to think about how to get deeper into Python within a CS > curriculum, I come up with a few ideas: > > (a) push more compsci content into the earlier grades so that CS1 might > move > more quickly from the beginning, and therefore get further. E.g. if a lot > of the students coming in already know some Python, this would be ideal. > > (b) keep the Python thread alive in CS2 even as Java is introduced, with > the > potential to bridge the two using Jython. This keeps Python around for > contrast. This may actually be closer to Zelle's own approach, as he > mentions at his website using Python as "pseudo code" for Java-based > implementations (but then current Java doesn't do operator overriding, so > some cool features of Python would still be missed using this approach). > > (c) think about returning to Python in CS3, if there is such. > > (d) return to Python in some of the more specialized classes having to do > with graphics, computational geometry, statistics or other specific > applications (a recommendation similar to (c) I suppose). > > (e) keep jiggering with the CS1 curriculum to squeeze more in, even if > students do not come in more prepared. > > When considering option (e), my attention goes to the Point class. If all > a > Point does is hold x and y coords, then a class implementation seems like > overkill in Python. You could get by with built-in tuples. But what if > we > make a Point slightly more interesting by making it a Vector? Then you > can > put in __add__ __sub__ __mul__ and __neg__, as well as length(self) and > maybe even dot(self,other) and cross(self,other) -- do one in the text, > leave the other for an exercise. Then there's conversion to/from > polar/spherical coordinates. > > Such a Vector might still be used as a parameter to Rectangle and Circle > constructors, as in the current version, i.e. it could start out as a > simple > (x,y) container, and gradually mature as new OO ideas are mentioned. > > Another approach would be to add a chapter called something like 'Looking > Ahead' or 'Advanced Python', wherein a lot of these cool features were > covered rather quickly and briefly, the intent being to give students a > foretaste. Those students most enamored of programming and wanting to > move > more quickly, could be directed to this chapter and a for-further-reading > section. > > However, none if this is about detracting from the worth of the text as it > stands. I believe Zelle is perfectly positioned to press Python's case, > and > is doing a very credible and creditable job of it. > > He's clear in his intro that his goal is less to teach Python than to give > an overview of important computer science concepts that students will > re-encounter in just about any language. He's consciously eschewing > certain > Python idioms (list comprehensions?) in favor of a more generic approach > because mastery of Python per se is not the main goal. I understand his > reasoning. > > Through his efforts, I'm hoping we quickly get to the point where "arguing > for Python" as a CS1 language becomes a no-brainer, i.e. it's not even a > point of controversy. I think this text moves us a big step in that > direction. It's clear, it works, and it should easily go into multiple > future editions. > > Kirby As much as I like Python, it doesn't walk on water. Arguing about CS1 languages usually degenerates into tedious religious battle where opposing sides argue the undeniable virtues of their language, and are generally disinterested in hearing about any other language. Yes, Python has lots of neat features, but so does every language, and arguing that Python's neat set of feature is better than language X's is a stalemate from the start. Productivity is far more important than language features, and the reason why Python trumps other languages is ultimately that it is so much easier to become productive in Python. I also think that if Python became known as the "beginner's language", then that would be a *much* bigger success than if it became the language of choice for CS1. Far more people program than take CS1 courses. Toby

4 4

zip
by Arthur 15 Dec '03

15 Dec '03

>Ain't 'zip' cool. >The problem that zip addresses occurred over and over in my code. (To Guido's chagrin) I do become fascinated and interested in language design issues. 'zip', for my purposes, was perfect. The intention, in my cases, is to iterate over lists of equal lengths. But there are corner cases in which the len of the lists become unequal, and I needed to test and adjust for that. My adjustment was exactly what zip provides - what the heck, go over the shorter of the two lists. Good enough for my purposes. Actually helped bulletproof my code. But only because there are parts of my code (when I'm just drawing, after all) where good enough is good enough. That is often not the case when programming. So as much as I appreciate 'zip' I recognize danger in it, because an unequal length list condition might also indicate an unexpected 'out of balance' condition as well as an expected one. That condition was more likely to be exposed with the 'old fashioned' way of handling the situation which zip addresses. So, in using zip, without some caution, an unexpected condition - a bug - might pass silently. The edu-sig relevance, I guess, is that there are always trade-offs, and therefore subtleties every way one turns. And, in the end, often no way to make things truly 'simple'. And students of the language, IMO, need to understand that upfront. And to take responsibility in all cases. It's all in the docs. But the reality is that probably the only way one is going to get one's arms fully around something as simple as the full implications of 'zip' is to get bitten by it once. Or at least that's how I end up learning most of the nooks and crannies. Having been bitten enough times and taken it like a .. (be careful) programmer, I sort of expect others to do the same. And get cranky when they don't. Which has been the base source of some of my crankiness when the issue of "newbies" and Python's responsibilities to them comes up again and again. Art

2 1

re: Graphing using Zelle's graphics.py
by Arthur 15 Dec '03

15 Dec '03

>for x1,x2 in zip(domain[:-1], domain[1:]) OT, to be sure, but: Ain't 'zip' cool. The problem that zip addresses occurred over and over in my code. It's appearance allowed me to clean-up code that otherwise seemed bothersome and inelegant. Now my code is perfect ;) Art

1 0

Graphing using Zelle's graphics.py
by Kirby Urner 15 Dec '03

15 Dec '03

John Zelle's graphics.py makes it easy for students to do graphics using Tk from within IDLE. Plus IDLE is making things somewhat easier these days, e.g. there's the 'restart shell' feature that clears out the memory without necessitating a reboot of IDLE. Suppose I wanted a quick sine and cosine graphs using graphics.py. Here's one way that might look: >>> from zelle.graphics import * >>> import math >>> def graph(f, domain, thewindow): """ Take a function, domain and target window, Return a graph """ for x1,x2 in zip(domain[:-1], domain[1:]): seg = Line( Point(x1,f(x1)), Point(x2,f(x2)) ) seg.draw(thewindow) >>> win = GraphWin('Graph',600,600) >>> win.setBackground('Blue') >>> win.setCoords(-10,-2,10,2) >>> domain = [i/100. for i in range(-1000,1000)] >>> graph(math.cos ,domain, win) >>> graph(math.sin ,domain, win) >>> win.close() The setCoords method is especially convenient, as it lets the user decide what the coordinate system will be. Kirby

1 0

re: Education Arcade
by Arthur 14 Dec '03

14 Dec '03

Richard writes - >Where simulations are interesting and even exciting teaching tools >is in the other extreme -- where the mapping from real to virtual is >uncontroversial, but the consequences of these known interactions >are unclear. This is generally the case when we are simulating physics. A nice, small non-technical and generic explanation of a physics SDK can be found at: http://opende.sourceforge.net/slides/slide1.html Also happen to like the presentation's aesthetics. The author, Russel Smith, created the Open Dynamics Engine (ODE): http://opende.sourceforge.net There is a Python wrapper to ODE, but for some reason the link is not working. So I will mention that there is an extant copy of a Windows binary for PyODE and Python2.3 which I had compiled, and made available some time ago at my own site: http://pw1.netcom.com/~ajs/download And, yes, I agree. Art

1 0

FW: [Edu-sig] re: Education Arcade
by Seabrook, Richard 14 Dec '03

14 Dec '03

Where simulations are interesting and even exciting teaching tools is in the other extreme -- where the mapping from real to virtual is uncontroversial, but the consequences of these known interactions are unclear. This is generally the case when we are simulating physics. An orbit-integrator is a prime example: there's no question about how gravity works, we can demonstrate that pretty trivially from real-world experiments and observations. On the other hand, the consequences of this are extraordinarily complex and unpredictable. A simulator can run that math at high speed and show you what you can expect. Furthermore, the actual experiment is basically impossible. Even if you had the multi-million dollar budget to launch a real object into space, the actual playing out of the orbital mechanics takes years. A simulation lets you run that fast-forward. ================================================================== Further on yours and Ms. Creighton's -- in this century we'll move human cognition from philosophy to physics, leading to reasonable definitions for thinking and learning. Perhaps then Ms. Creighton will get better feedback. Dick S.

1 0

Re: Python Programming: An Introduction to Computer
by Arthur 14 Dec '03

14 Dec '03

Guido writes: >...and I am seeing some posts from Arthur that I can actually understand. I've run it through numarray. Turns out, law of averages :) Art

1 0

re: Python Programming: An Introduction to Computer Science
by Toby Donaldson 14 Dec '03

14 Dec '03

> In my view, we need more programming in the mathematics curriculum, which > means recognizing that writing programs is likewise a way of writing > mathematics. Or, more accurately, I'd say both kinds of writing are > similar kinds of symbolic activity which deserve a prime spot in K-12 > education. I think teaching math and programming is a very interesting idea ... proofs are just a kind of code walkthrough. Toby -- Dr. Toby Donaldson Assistant Professor School of Interactive Arts and Technology Simon Fraser University

2 1