Mailman 3 September 2006 - Edu-sig

Re: [Edu-sig] The fate of raw-input() in Python 3000
by Hugh Stewart Sept. 12, 2006

Sept. 12, 2006

Hi All, After 30 odd years of teaching 'programming' in many languages and at many levels; (High School, College, University) I have come up with the 10:20:70 rule of thumb. 10% of students will have a natural flair, 20% will make competent programmers and the remainder struggle with many of the concepts (This does not mean they don't gain from the experience, in many cases they do). Hence the majority of the students in any group(class) will be the 70%ers and so any assistance from the language is to be valued and the raw_input() and to a lesser extent input() I/O syntax have great value to the beginner. The comments of Dan Crosta ring true for many students. On retirement I toyed with the idea of turning the copious notes I had developed for students into a book/textbook. At the time Python v1.5.2 had just been released and it looked interesting as the language for the book. I took the hundreds of exercises and assignments and reworked them in Python. It was enjoyable. It was also interesting in comparing the strengths and weaknesses displayed relative to earlier languages. As an illustration: an exercise lifted from Oh! Pascal, 2nd. ed. Norton p229-233. Write a program that produces palindromic numbers by the following algorithm: "Start by taking a number. If it isn't a palindrome, reverse the number,sum the number and its reversal. If the new number isn't palindromic reverse the new number, then add it to the reversal. Eventually, the number will become a palindrome." After a few iterations either a palindrome is found or an overflow is reported due to the limitations of the integer representation in most languages. Then, I had neither the time nor interest to develop an extended solution. Since Python 2.3 the extended solution is quite simple (almost trivial) using long integers and extended slices. With this Python generated productivity I had time to play and enter a few numbers at random via raw_input() and to my suprise the number 879 (978) did not produce a palindrome after 100000 iterations. I immediately thought --- here is a conjecture: Not all numbers produce a palindromic number. Some time later a Google search produced the following site of interest: http://mathworld.wolfram.com/PalindromicNumberConjecture.html. To cut to the chase: raw_input() provides an extremely useful I/O function for simple exercise type problems which are so essential in building a beginners repertoire of programming techniques and for 'John Zeller' type problems ( simple quick dirty and effective solutions that get those housekeeping jobs done). Python gives us a programming language of extraordinary productivity at all levels of programming (especially for beginners). Just for Kirby: Buckminster Fuller even says something about palindromic numbers. See http://en.wikipedia.org/wiki/Palindromic_number Hugh

3 2

Re: [Edu-sig] simple guessing games
by kirby urner Sept. 11, 2006

Sept. 11, 2006

Given we've learned how dot notation triggers behaviors, of strings, of lists, of modules, we now look at our snake's internal __rib__ syntax. Mnemonic (also legal Python, even if __rib__ isn't really a special name [1]): class Snake: """triggering reflexes...""" def __rib__(self): pass def __rib__(self): pass def __rib__(self): pass def __rib__(self): pass def __rib__(self): pass def __rib__(self): pass def __rib__(self): pass def __rib__(self): pass Both __init__ and __repr__ are special methods, ready for our use.[2] [1] http://www.dbforums.com/showthread.php?t=407220 [2] http://www.python.org/doc/current/ref/specialnames.html ======== import random class Secret: def __init__(self): self.__hidden = random.randint(0,100) def guess(self, val): if val > self.__hidden: print "too high" elif val < self.__hidden: print "too low" else: print "You guessed it!" def __repr__(self): return 'A secret number' ======== >>> from sillygame import Secret >>> thesecret = Secret() >>> thesecret.guess(10) too low >>> thesecret.guess(50) too low >>> thesecret.guess(75) too low >>> thesecret.guess(85) too low >>> thesecret.guess(95) too low >>> thesecret.guess(100) too high >>> thesecret.guess(96) You guessed it! === Good work mom! Kirby

2 12

Re: [Edu-sig] simple guessing games
by Daniel Ajoy Sept. 11, 2006

Sept. 11, 2006

On 9 Sep 2006 at 0:28, edu-sig-request(a)python.org wrote: > From: Dan Crosta <dcrosta(a)sccs.swarthmore.edu> > Subject: Re: [Edu-sig] The fate of raw_input() in Python 3000 > > When I think back to when I was learning to program in 9th grade (I'm > not a professional software devel) I know that it was really exciting to > be able to twiddle with the computer for a bit, then call my mom over > and have her work with my program -- simple guessing games, ... > > But even > though it did, it would not have been as exciting to sit my mom down > with it and let her play around, and I wouldn't want to have to explain > to her (even now with a nearly infinitely more sophisticated > understanding of computers and programming than I did in my first > months) what a function is, how to interact with it, what arguments are, > etc. The following is in Logo. I put the this in a text file: ======================= to i.guess :number if :number < :initial.guess [ print [your guess is less than my number.] ] if :number > :initial.guess [ print [your guess is greater than my number.] ] if :number = :initial.guess [ print [You got it! To try again type: restart] ] end to restart print [Guess a number between 0 and 99] print [Type: i.guess number] make "initial.guess random 100 end restart ======================= Then when I clic on the icon of that file I get: (In Logo the prompt is "?") Guess a number between 0 and 99 Type: i.guess number ? i.guess 50 your guess is less than my number. ? i.guess 70 your guess is less than my number. ? i.guess 80 your guess is less than my number. ? i.guess 90 your guess is greater than my number. ? i.guess 85 your guess is greater than my number. ? i.guess 83 your guess is less than my number. ? i.guess 84 You got it! To try again type: restart ? restart Guess a number between 0 and 99 Type: i.guess number ---- I'm passing arguments to functions. I'm not using "raw_input", I'm using the prompt. AND I'm not teaching mon what a function is. :) Daniel

1 0

Re: [Edu-sig] Edu-sig Digest, Vol 38, Issue 21
by Toby Donaldson Sept. 10, 2006

Sept. 10, 2006

> Now Python is evolving into Python 3000. Will a valid Python program be a valid > Python 3000 program? This is important. At Vancouver Python workshop this summer, Guido talked about this very point. He mentioned two extreme examples: the current committe work on C++, and Perl 6. C++ is trying *very* hard to remain backwards compatible, while Perl 6 is not. He says he wants Python 3000 to be somewhere in the middle. So source compatibility isn't planned, but migration tools are planned. David Mertz's gives more details in a summary of one of Guido's talks (from OSCON): http://www-03.ibm.com/developerworks/blogs/page/davidmertz?entry=second_day… For the kind of simple programs that appear in beginning programming courses, I expect around 100% of the code to be trivially convertible. Toby -- Dr. Toby Donaldson School of Computing Science Simon Fraser University (Surrey)

2 2

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

Sept. 10, 2006

> > 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'. 'stdin' is probably meaningless to beginners. I think beginners would prefer clear, simple names that don't require experience with Unix or Java. :-) > 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 * Yes, that would be awful. Don't do that. :-) By using a better package name and a more explicit import you could get something that reads better like from userinput import raw_input Or another approach would be to have a package named "user" or "keyboard", so you could write things like import keyboard answer = keyboard.raw_input("Morbo demands an answer: ") Another possibility, is to follow Java's Scanner class: import java.util.Scanner; ... Scanner sc = new Scanner(System.in); System.out.printf("Enter the circle's radius: "); double radius = sc.nextDouble(); A Python version could put the scanner in the main namespace, and allow code like this: print "Enter the circle's radius: " radius = scanner.next_double() print "Enter the circle's name: " name = scanner.next_line() I would prefer a name other than "scanner", but this gives the main idea. This approach has a couple of nice features: - the code is explicit and easy to read --- you can tell just by looking where a double is wanted and where a string is wanted - meaningful, custom error messages can be supplied, i.e. if the next input is not a valid double, then next_double can say it expected a double but found none, next_int could say it expected an int, etc.; this is preferable to the inconsistent behaviour of input: >>> input("Enter radius: ") Enter radius: 4 4 >>> input("Enter radius: ") Enter radius: four Traceback (most recent call last): File "<stdin>", line 1, in ? File "<string>", line 0, in ? NameError: name 'four' is not defined >>> input("Enter radius: ") Enter radius: for Traceback (most recent call last): File "<stdin>", line 1, in ? File "<string>", line 1 for ^ SyntaxError: unexpected EOF while parsing > 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. In the Python course I teach, students need to import .py files they write into the interpreter (for testing), so they very soon need to write statements like >>> from lab2 import * Also, the very first statement students see is: >>> import turtle It is not hard to explain this in a way so that beginners can understand it well enough to use it. More details and subtleties of modules and imports come later, as needed. > 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). Its kind of like the nonsense explanations you see for the Python "print" statement and "+" operator. :-) Teaching is filled with IOUs. We often use things before we completely understand them. Toby -- Dr. Toby Donaldson School of Computing Science Simon Fraser University (Surrey)

7 31

Python and pre-Calculus
by Kevin Driscoll Sept. 10, 2006

Sept. 10, 2006

I'm teaching Pre-Calculus for the first time this year and am hoping to integrate Python as often as possible. My syllabus is focused on exploring functions in various forms, uses, and contexts. The intersections to programming are numerous and beautiful. I'd love to get a brainstorm happening here. Especially addressing the college educators, what do you which your freshman had seen in 11th and 12th grade? Yesterday we worked on building a complete mathematical definition for a Toaster function. Wouldn't you know it? toaster(bread) = toast ... every time! Kevin

2 3

IronPython 1.0 on Slashdot
by kirby urner Sept. 10, 2006

Sept. 10, 2006

As someone consistently upbeat about .NET and Mono (pronouced moe no, not mah no), I share Jim's excitement for the future. Will this be the last year I teach CPython for Saturday Academy? (I doubt it). Kirby >From Slashdot: "IronPython version 1.0 was just released after 3 years of development. Jim Hugunin, the creator of Jython and the lead developer of the Shared Source IronPython, made the birth announcement earlier this week. From the announcement: 'I wanted to understand how Microsoft could have screwed up so badly that the CLR was a worse platform for dynamic languages than the JVM... I found that Python could run extremely well on the CLR — in many cases noticeably faster than the C-based implementation. [...] Shipping IronPython 1.0 isn't the end of the road, but rather the beginning. Not only will we continue to drive IronPython forward but we're also looking at the bigger picture to make all dynamic languages deeply integrated with the .NET platform and with technologies and products built on top of it. I'm excited about how far we've come, but even more excited by what the future holds!'" http://developers.slashdot.org/article.pl?sid=06/09/06/2134234&from=rss

4 10

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

Sept. 9, 2006

*I'd love to send the photo, but alas mailings lists don trust inline graphics:-( * ***http://www.news.com.au/sundaytelegraph/story/0,,20372915-5006003,00.html * *Jason * *-------------------------- * *A LITTLE bloating after a big meal is an occupational hazard for pythons. But this unfortunate creature found itself unable to slink away and sleep it off.* In fact, after swallowing a pregnant sheep, it couldn't move at all. Firemen in the Malaysian village of Kampung Jabor, about 190km east of Kuala Lumpur, easily caught it after it was spotted on a road. Conservationists were yesterday still deciding whether to keep the 90kg snake in a zoo or release it back into the wild. Pythons eat no more than once a week but when they open their incredible hinged jaws, anything is fair game. This 5.5m python found its eyes were definitely bigger than its belly. In July surgeons were forced to operate on a 4m Burmese python after it inadvertently swallowed a queen-size electric blanket. Humans also have become victims. In 1972 a python in Burma swallowed an eight-year-old boy. But sometimes their food really doesn't agree with them. In October last year, a 3.6m python came off second best in Everglades National Park in Florida. The snake, which tried to swallow a 1.8m alligator whole, exploded, said scientists who found the gory remains.

2 2

Re: [Edu-sig] Python and pre-Calculus
by Daniel Ajoy Sept. 9, 2006

Sept. 9, 2006

On 8 Sep 2006 at 18:00, edu-sig-request(a)python.org wrote: > From: "Kevin Driscoll" <driscollkevin(a)gmail.com> > Subject: [Edu-sig] Python and pre-Calculus > > I'm teaching Pre-Calculus for the first time this year and am hoping > to integrate Python as often as possible. My syllabus is focused on > exploring functions in various forms, uses, and contexts. The > intersections to programming are numerous and beautiful. > > I'd love to get a brainstorm happening here. Especially addressing > the college educators, what do you which your freshman had seen in > 11th and 12th grade? > > Yesterday we worked on building a complete mathematical definition for > a Toaster function. Wouldn't you know it? toaster(bread) = toast ... > every time! What happens when you enter: toaster(hand)? I'm brainstorming now: * Turn calculus around. Start with programming functions and talking about them as machines that receive something and output something. It is good that machines be reliable so that with a certain input we can only obtain a specific output. We can't input something and obtain nothing. We can input something at diferent times and obtain different outputs. * Take two x's and apply your function to obtain their corresponding y's . You can talk about the rate of change: by how much does Y changes when we go from x=1 to x=2? Does Y change by the same ammount if we go from x=10 to x=11? * The car analogy: at any given moment a car has a certain speed. If our function is SpeedAt(time) can we calculate the value of the speed of the car, say at time= 10 What happens if the car made stops? What happens if at some point we decided that we were running late and decided to go faster? We can program SpeedAt(time) with if's like if time between 0 and 1 then speed = 10 * time if time between 1 and 10 then speed = 10 if time between 10 and 11 then speed = -10 * time + 110 if time between 11 and 12 then speed = 10 * time - 110 if time between 12 and 30 then speed = 10 if time between 30 and 32 then speed = 5 * time - 140 if time between 32 and 99 then speed = 20 if time between 99 and 100 then speed = -20 * time - 2000 accelation is the rate of change of velocity. How much does velocity change between 1 and 5? SpeedAt(5)-SpeedAt(1) / (5-1) How much does it change between 11 and 12? Program a function RateOfChange(start,finish) How much does it change between 0 and 100? But that's an average acceleration. At some points during the trip the car had postive accelerations and at some points it had negative accelerations, all those canceled out. But at any give time the car has an acceleration, (probably=0) this is an instantaneous acceleration. How would you calculate the acceleration at time = 13? or at time = 31? The answer is the invention of epsilon. and the definition of derivative. Then write the program: InstantaneousRateOfChange(time) if SpeedAt(time) = -0.2 * time ^ 2 + 4 * time how does InstantaneousRateOfChange(time) behave? how does its plot look like? Is this plot a line? Using points in the plot can you come up with the equation of this line? Oh, it's IROC = -0.4 * time + 4 ... how interesting... * Can you know the "Distance from home" by only knowing how SpeedAt(time) behaves. The answer is the concept of integration. A program can be made that approximates the integrals using Riemann (sp?) sums. * The mid interval theorem is directly related with the strategy for solving the "guess a number" game. This is called the Bisection method for finding roots. Daniel

1 0

Oh, the TEACHERS!
by Kevin Driscoll Sept. 9, 2006

Sept. 9, 2006

> I'm sick of these "teachers" you keep talking about. They should all > just go away, and let the real programmers have their jobs. Don't > even *think* about teaching Python if you haven't coded in it > professionally and made real money off it. That's closer to my > attitude than "oh, the teachers are upset, we should care." In my coding days, I rarely used Python but I use it almost exclusively in teaching (9-12th grade, high school.) I take issue with the hyperbole above but want to steer away from the former thread title. Great developers are not by nature great teachers. Likewise, great teachers may not be great developers. Rather than choosing the either-or proposition, the two ought to work together. I have had great success bringing professionals into my classroom to be guest judges for programming competitions or to present a project with which they are engaged with in the workplace. This complementary system helps students see the connection between their schoolwork and the "real world" very concretely. The poison leaks not from any individuals but rather from the schism between academia and the rest of the programming world. Kevin

4 3