Mailman 3 September 2006 - Edu-sig

Python bites off more than it can chew
by Jason Cunliffe Sept. 9, 2006

Sept. 9, 2006

http://www.news.com.au/sundaytelegraph/story/0,,20372915-5006003,00.html

1 0

Re: [Edu-sig] The fate of raw_input() in Python 3000
by Toby Donaldson Sept. 8, 2006

Sept. 8, 2006

> Removing input() FORCES people to have to address import, streams, dot notation, > functions, and strings. How does using the input function avoid the use of functions? :-) Keep in mind that most students have no problem *using* unexplained features if there is a good reason to use them. For instance, most don't freak out because we don't actually tell them how "print" or "+" works. > The whole point of keeping input() is to give the teachers a choice to do > interesting things without introducing (in their mind) unnecessary topics > or syntax. To be honest, even though input() doesn't really matter to me, I find the arguments against it stronger than those for it. I think your letter needs strong arguments for keeping input. I think two points win the day: - it does not appear to be used by as many teachers as raw_input - it is trivial to simulate if you have raw_input > Personally, I have to address import fairly early for other reasons, and > have never really used input(). But I don't want to make John Zelle teach > the way that I do. I think it is okay, however, for a language to make questionable programming practices harder to use. It seems like a good way to prevent errors for everyone who uses the language. > Java gives us no choice at all. Talk about "there's one way to do it." You > must deal with too much stuff to make the computer do something, anything. Actually, Java has many ways to do most things ... for example, reading input can be done with the Scanner class, or various other combinations of IO classes. If what you mean is that Java requires the use of a lot of syntax for simple programs, then I agree. But in my experience in teaching Java, I think that problem is vastly over-stated by most people who use that argument. It is an annoyance of Java to be sure, but most students are able to use things before they completely understand them. Toby -- Dr. Toby Donaldson School of Computing Science Simon Fraser University (Surrey)

1 0

Re: [Edu-sig] The fate of raw_input() in Python 3000
by Radenski, Atanas Sept. 7, 2006

Sept. 7, 2006

> -----Original Message----- > From: edu-sig-bounces(a)python.org [mailto:edu-sig-bounces@python.org] > On Behalf Of Toby Donaldson > What if instead of naming the package "teaching", it was called > something less offensive, like "simpleIO" or "userinput" or > "interactive" or "convenience"? This is a plausible way to remove the 'teaching' label. I would prefer 'stdin'. Now imagine a beginner who is looking at her very first Python program. The first line she will see in her first program ever will be this: from stdin import * This person and her instructor will have to deal with modules and import FIRST, although the student is not likely to develop multi-modular programs at the very beginning. I wonder how is the instructor going to tell her what is the meaning of 'from stdin import *'? I guess, in the same way instructors tell what 'public static void main (...) is'. In this way we are going to the Java nonsense (nonsense from the perspective of teaching beginners, of course, otherwise Java is a wonderful language). This discussion is difficult because people speak form tow different perspective: the teacher's perspective vs the developer's. In this thread I have a teacher's perspective. I would like to see Python keep, rather than loose its edge as a beginner's language. John Zelle explained what that means very well - several times in this thread only. Let us have more teachers teach Python, and more beginners study and enjoy it. Then we will probably have more Python developers as well. > Toby Atanas

1 0

Re: [Edu-sig] The fate of raw_input() in Python 3000
by Toby Donaldson Sept. 7, 2006

Sept. 7, 2006

> > I've been watching this discussion and wondering - how much of the > > problems > > people complain about would go away if here was a "teaching" > distribution > > of > > python. That is one that did the equivalent of > > > > from teaching import * > > Nowadays, college students want to do "real programming". You call a > language 'teaching' - you loose. I actually have to work hard to > convince my students that Python is not just a teaching language, but a > language for real work. I show them various rankings based on use, > salaries, jobs, etc. > > A great thing about Python is that it is popular in commercial projects > and at the same time, you can teach beginners with it. IMHO, this is one > of the most distinguishing features of Python in comparison to other > languages > > > from teaching import * > > This will immediately create two difficulties. > 1. You implicitly declare to your students you are not dealing with > "real programming". > 2. You most likely have to tell your entry-level students that you > cannot explain what the above thing means, but you will tell them later. > People switch form Java to Python to *avoid* this kind of situations. What if instead of naming the package "teaching", it was called something less offensive, like "simpleIO" or "userinput" or "interactive" or "convenience"? Toby -- Dr. Toby Donaldson School of Computing Science Simon Fraser University (Surrey)

2 1

Re: [Edu-sig] The fate of raw_input() in Python 3000
by Radenski, Atanas Sept. 6, 2006

Sept. 6, 2006

> -----Original Message----- > From: edu-sig-bounces(a)python.org [mailto:edu-sig-bounces@python.org] On > Behalf Of Michael > Subject: Re: [Edu-sig] The fate of raw_input() in Python 3000 > > I've been watching this discussion and wondering - how much of the > problems > people complain about would go away if here was a "teaching" distribution > of > python. That is one that did the equivalent of > > from teaching import * Nowadays, college students want to do "real programming". You call a language 'teaching' - you loose. I actually have to work hard to convince my students that Python is not just a teaching language, but a language for real work. I show them various rankings based on use, salaries, jobs, etc. A great thing about Python is that it is popular in commercial projects and at the same time, you can teach beginners with it. IMHO, this is one of the most distinguishing features of Python in comparison to other languages > from teaching import * This will immediately create two difficulties. 1. You implicitly declare to your students you are not dealing with "real programming". 2. You most likely have to tell your entry-level students that you cannot explain what the above thing means, but you will tell them later. People switch form Java to Python to *avoid* this kind of situations. > Michael Atanas

1 0

Re: [Edu-sig] The fate of raw_input() in Python 3000
by Radenski, Atanas Sept. 5, 2006

Sept. 5, 2006

> -----Original Message----- > Behalf Of Brad Miller > I too will add one more voice to this chorus, in the hope that > numbers will influence Guido. Me too :-) I would like to see both input and raw_input preserved. Replacing these with more complicated (from pedagogical perspective) methods would probably give an additional reason for educators to look at alternative languages, such as Ruby. There were questions in this list of the appropriateness of the names of the two functions. To me, the names of input and raw_input seem just fine. One can tell students that the input function is more general and interprets the input character sequence as a Python expression, finally delivering its value. In contrast, raw_input is simpler and interprets nothing - simply delivers the input string as a character string. It is logical. Just my ten cents. Atanas Atanas Radenski mailto:radenski@chapman.edu http://www.chapman.edu/~radenski/ There are wavelengths that people cannot see, there are sounds that people cannot hear, and may be computers have thought that people cannot think -- Richard Hamming

2 1

Re: [Edu-sig] The fate of raw_input() in Python 3000
by Toby Donaldson Sept. 5, 2006

Sept. 5, 2006

> The following is something I have been pondering for quite a while now > and am wondering what other people on this list think. > > According to PEP 3100 > (http://www.python.org/dev/peps/pep-3100/ ) > raw_input() [as well as input()] is recommended for removal from the > built-in namespace, to be replaced by sys.stdin.readline(). Let me add my voice to the chorus: removing raw_input() hurts beginners, and, for beginners, it is far preferable than the proposed alternative, which is cryptic and overly specific. I saw Guido's Python 3000 talk at the Vancouver Python Workshop this summer, and I am pretty sure he did not mention this (it was on my mind --- I had read the PEP earlier). I If raw_input were removed, then I expect we would see what happened in the Java world in the early days: every teacher and textbook uses their own home-rolled simple IO package. I hope Python 3000 does not repeat Java's mistake! I don't care about "input". Its there now and hasn't ever been useful to me (eval(raw_input("...")) is a fine alternative), and, more importantly, has apparently not caused confusion among students. Toby -- Dr. Toby Donaldson School of Computing Science Simon Fraser University (Surrey)

4 4

Ramanujan's Pi (an exercise with generator & decimal features)
by kirby urner Sept. 5, 2006

Sept. 5, 2006

So here I'm using Python's new extended precision decimal type with one of Ramanujan's crazy pi engines: http://people.bath.ac.uk/ma2lg/project/ramanuja.htm I also used another generator I wrote earlier to get root8 to a lot of digits. Here: http://www.4dsolutions.net/ocn/python/roots.py Factorial -- fact(n) -- is implemented back stage (easily done). As you can see, Python does a great job getting a lot of digits. ======================================================= from __future__ import division from decimal import * getcontext().prec = 100 # setting high precision standard! def pieinsky(): c1 = Decimal(4) c2 = Decimal(1103) c3 = Decimal(26390) c4 = Decimal(396) c5 = Decimal(9801) # code formatted for readability (make it be one line) root8 = Decimal('2.82842712474619009760337744841939615 7139343750753896146353359475981464956 9242140777007750686552831454700276') i = Decimal(0) thesum = Decimal(0) while True: term = (fact(c1*i)*(c2 + c3*i))/(pow(fact(i),4)*pow(c4,4*i)) thesum = thesum + term yield 1/((root8/c5)*thesum) i += 1 >>> pigen = pieinsky() >>> pigen.next() Decimal("3.1415927300133056603139961890252155185995816071100335596565362901= 28551455441321642740854085209704228") >>> pigen.next() Decimal("3.1415926535897938779989058263060130942166450293228488791739637915= 05784400648511674693278393849439482") >>> pigen.next() Decimal("3.1415926535897932384626490657027588981566774804623347811683995956= 44739794558841580205059234965983146") >>> pigen.next() Decimal("3.1415926535897932384626433832795552731599742104203799112167038960= 06945787942847069061241208907980917") >>> pigen.next() Decimal("3.1415926535897932384626433832795028841976638181330306239761655909= 98553105507509100070309837894567968") >>> pigen.next() Decimal("3.1415926535897932384626433832795028841971693993798468327435125072= 81953256921043725789395219809199167") >>> pigen.next() Decimal("3.1415926535897932384626433832795028841971693993751058210209332424= 69729074078272131764032273329551022") >>> pigen.next() Decimal("3.1415926535897932384626433832795028841971693993751058209749445927= 57814327091194665469239192568221775") >>> pigen.next() Decimal("3.1415926535897932384626433832795028841971693993751058209749445923= 07816410719485095770076209900585536") >>> pigen.next() Decimal("3.1415926535897932384626433832795028841971693993751058209749445923= 07816406286209042542808018278896595") >>> pigen.next() Decimal("3.1415926535897932384626433832795028841971693993751058209749445923= 07816406286208998628035262302197974") >>> pigen.next() Decimal("3.1415926535897932384626433832795028841971693993751058209749445923= 07816406286208998628034825342121433") >>> pigen.next() Decimal("3.1415926535897932384626433832795028841971693993751058209749445923= 07816406286208998628034825342117070") Stops changing at this point -- limit reached. It's correct to last two digits, per http://www.mathwithmrherte.com/pi_digits.htm Kirby

1 1

Fwd: [Rur-ple-devel] Crunchy screencast
by Andre Roberge Sept. 4, 2006

Sept. 4, 2006

Demo ... for those interested.... André ---------- Forwarded message ---------- From: Igor TAmara <igor(a)tamarapatino.org> Date: Sep 3, 2006 10:39 PM Subject: [Rur-ple-devel] Crunchy screencast To: rur-ple-devel(a)lists.sourceforge.net Hi, I just made a screencast showing a couple of things that can be done with crunchy, don't hesitate to use it or put it on screenshots, maybe the people interested can take a look :) http://igor.tamarapatino.org/recursos/scrvideo/democrunchy.html Thanks for such inspiring work, crunchy rocks.

3 2

More on Dead Languages
by kirby urner Sept. 1, 2006

Sept. 1, 2006

So I was going over the M situation with Bernita this morning (a health care data tech I know), talking up the predicament at the VA (Veterans Administration), made known to me recently by UC Davis (an active MUMPS/M center). A short memorable form of my currently favorite strategy is "suMerian" i.e. intersect the computer field's challange to recruit dead language programmers with a problem already solved in Antiquities (one of the humanities): make "knowing a dead language" (one or more) a really cool attribute, a source of perks and kudos within the department. That *doesn't* mean you can't also speak the current vogue lingo, Ocaml or whatever. Specialize in two why not: one that's fresh on the scene and one that's relatively ancient, and yet still running some important machines. This, I think, is a far better solution that rewriting and rewriting working code, simply to "keep it in a language we understand or we'll never be able to debug it or enhance it." That *sounds* like a reasonable strategy until you look at the cost in human resources. "Hey, let's take a perfectly good operating system with this tiny glitch, and junk it for this other one, because we don't know any C anymore" -- that'd be the end of Linux right there, and just because it didn't have some new features we wanted. Nobody cared much for C anymore, now that GUIs were so easy, so now it all comes crashing down around us. What a stupid development that'd be. Like leaving the Planet to Eloi, with not a Morlock in sight. So here's my proposal: First, the one I've already made many times (and not just on this list): that CS0 intro/survey courses be whiz bang and more fun, more of a three ring circus, with lots of concepts coming and going, giving candidate majors some dizzying experience of the wide-open field in front of them, if they only apply themselves within our discipline. Second, steal unashamedly from the humanities if there's already an easy fix, in our case a failure to produce enough staff with the right skills to satisfy academia, industry, government and the media (who did I leave out? just consider healthcare and entertainment as industries, religion as all or none of the above). What that looks like in practice might be frontloading with an "easy" language such as Python (you've gotta admit, it's really clean OO), then putting some forks in the road, one going to Java, but another going directly to C, into the guts of our favorite snake. Then bridge to C# by dissecting the same snake yet again. In Java, maybe go with Jython and look at some of that source code. What all these roads have in common: we're getting that an agile language on the surface, is likely a system language under the hood. Something faster to run, but slower to write, now supports something faster to write, but slower to run. Since runtime is plenty fast, we go for the fast writing. But slow writing is still a very much needed skill, IF you're going to go higher on the computer science ladder. I was explaining to Barry and pbd on Barry's boat yesterday about Knuth and his invented software/hardware for encoding the algorithms. A passage of taut and sometimes funny prose, telegraphs to our minds, but then the stupid machine has to be taught, and that takes a funny language. Knuth supplies one that's appropriately low level to keep us living in hardware, just above the metal. That's not a level we're supposed to let go of. We've got to keep a lot of focus there. And so computer science needs that "nose dive" possibility, that after CS0/CS1 a complement of courageous code jockeys will "head for the basement" to study the inner gearworks. Mostly others will do the puppets and animations I mostly write about, given that's what I know best. But that doesn't mean I'm unaware of my peers, and their admirable skills. Assembler language is not really my bag unlike with Barry, a banker, who makes money off it (on code he wrote himself mind you, inside of some kind of power boat dimmer switch). I've never had to, even though I studied it in college, and later in those Peter Norton books. I do make money with Python though, though not yet as much as with Visual FoxPro. Kirby Portland Knowledge Lab Portland "open source capital" Oregon

1 0