Python @ Education: What are your problems?
Hello, are you using python for teaching programing? I am just writing a diploma paper about python and want to know your experiences with python. What do you like when teaching python? For example: - Easy readable syntax - High Level language - Lists, Tupels, Dictionaries included - interpreter: Everything can be tested - Many tools available ..... AND MORE IMPORTANT: What are your problems with python? Are pupils/students having any problems or often asked questions? What do you dislike at python? For example: - When teaching C or Pascal, newbies do not know, where to set a ";" and where not. Any similar problems with Python? - Why must I set a ":" after "if" or "for" ? " if x == y : " ..... I hope you have many suggestions. regards, Ingo
On Thu, May 30, 2002 at 12:47:25AM +0200, Ingo Linkweiler wrote:
are you using python for teaching programing?
We're about to start. We've been running quasi-competetive trials of Python and C, with a view to replacing the current Pascal implementation of the undergraduate programming syllabus here as the University of Oxford's Physics department.
I am just writing a diploma paper about python and want to know your experiences with python.
What do you like when teaching python? For example: - Easy readable syntax
Check.
- High Level language
Check. We would never consider teaching anything ``low-level'' in scientific programming (C doesn't count).
- Lists, Tupels, Dictionaries included
Not bothered for our purposes. Lists are mentioned only very briefly in the context of the range() function, but we got away without discussing tuples or dictionaries at all. I say ``got away'' because we only have 1 day to teach programming(!) so almost anything we can avoid we will.
- interpreter: Everything can be tested
I thought this was going to be a big deal. We designed the trial to give students almost a free reign over whether to use modules or the interpreter and *none* of them (out of about 40) used the interpreter. I think this might be due to the length of the programs they were writing (none more than about 100 lines), so they can derive practically the same amount of interactivity from repeatedly re-running the the program. Perhaps when asked to write longer programs, when it becomes unwieldy to make changes for debugging purposes they might use it.
- Many tools available
The standard library is nice, but we make particularly heavy use of Numeric Python and Gnuplot.py
AND MORE IMPORTANT: What are your problems with python? Are pupils/students having any problems or often asked questions?
At the moment it's hard to determine if the consistent problems are due to the way the course is written OR peculiar to Python OR generic problems that students would encounter in learning programming in every language. We do seem to be having some trouble with the inconsistency of writing to stdout and file. To make things easier early on we have them write to screen using the print command. They can then separate abritrary variables using commas. However then they do fout.write(myfloat, myint, "Some numbers") and it doesn't work they get confused. It may be better to teach them to write to screen using sys.stdout.write from the start as that then provides a consistent writing tool.
What do you dislike at python?
Input of whitespace separated numbers from file or stdin is relatively complex in Python:
line = raw_input() snumbers = string.split(line) x, y = float(snumbers[0], snumbers[1])
unless I'm missing something obvious. The comparable expression in Pascal is readln(x, y)
Any similar problems with Python? - Why must I set a ":" after "if" or "for" ? " if x == y : "
I explain this by appealing to their understanding of grammar: A colon introduces a new idea. (Apologies to whoever it was came up with that explanation on either this list or tutor). They seem to forget it quite regularly, but the error message leaves nothing to the imagination. If you (or anyone) are interested in seeing the handbook for the course, from which our students work, then I could post the URL to a *work in progress* version of it here. It's available in HTML, PDF and PS. -- Michael
- Lists, Tupels, Dictionaries included
Not bothered for our purposes. Lists are mentioned only very briefly in the context of the range() function, but we got away without discussing tuples or dictionaries at all. I say ``got away'' because we only have 1 day to teach programming(!) so almost anything we can avoid we will.
It seems your course is somewhat unusual in that apparently has a heavy focus on scientific computing. Not surprising given that you're in the Physics program! Usually data structures are a very important part of a programming curriculum, and then lists and dicts are crucial. Does this mean you represent all arrays of numbers with Numeric arrays?
- interpreter: Everything can be tested
I thought this was going to be a big deal. We designed the trial to give students almost a free reign over whether to use modules or the interpreter and *none* of them (out of about 40) used the interpreter. I think this might be due to the length of the programs they were writing (none more than about 100 lines), so they can derive practically the same amount of interactivity from repeatedly re-running the the program. Perhaps when asked to write longer programs, when it becomes unwieldy to make changes for debugging purposes they might use it.
Interesting. Could it also be that your students have reasonable computer experience on Windows, where an interactive command line interface is not used?
We do seem to be having some trouble with the inconsistency of writing to stdout and file. To make things easier early on we have them write to screen using the print command. They can then separate abritrary variables using commas. However then they do fout.write(myfloat, myint, "Some numbers") and it doesn't work they get confused. It may be better to teach them to write to screen using sys.stdout.write from the start as that then provides a consistent writing tool.
Point taken. It's just that sys.stdout.write is so cumbersome to produce neat-looking output. :-( I wonder what could be done to fix this? Making write() act more like print is impossible for backwards compatibility reasons (separate print calls always insert a space or a newline between data, and separate write() calls do neither). Maybe we should add a file method f.printf("format string", args) and a built-in function printf("format string", args) and deprecate the print statement??? --Guido van Rossum (home page: http://www.python.org/~guido/)
On Thu, May 30, 2002 at 08:44:26AM -0400, Guido van Rossum wrote:
- Lists, Tupels, Dictionaries included
Not bothered for our purposes. Lists are mentioned only very briefly in the context of the range() function, but we got away without discussing tuples or dictionaries at all. I say ``got away'' because we only have 1 day to teach programming(!) so almost anything we can avoid we will.
It seems your course is somewhat unusual in that apparently has a heavy focus on scientific computing. Not surprising given that you're in the Physics program!
Indeed.
Usually data structures are a very important part of a programming curriculum, and then lists and dicts are crucial. Does this mean you represent all arrays of numbers with Numeric arrays?
Yes.
- interpreter: Everything can be tested
I thought this was going to be a big deal. We designed the trial to give students almost a free reign over whether to use modules or the interpreter and *none* of them (out of about 40) used the interpreter. I think this might be due to the length of the programs they were writing (none more than about 100 lines), so they can derive practically the same amount of interactivity from repeatedly re-running the the program. Perhaps when asked to write longer programs, when it becomes unwieldy to make changes for debugging purposes they might use it.
Interesting. Could it also be that your students have reasonable computer experience on Windows, where an interactive command line interface is not used?
Yes. Five years ago we made the assumption that students had *no* experience. Now we make the assumption that they have Windows experience (I'll leave the question of which one is preferable as an exercise for the reader ;->). They seem to find the UNIX environment quite difficult for the first couple of hours, and I don't doubt that an unwillingness to work intereactively in Python is related. In the handbook we insist they use the Shell only once (for the ``hello world'' program). Perhaps we should have them use it for a little longer. Interestingly, the experienced UNIX users and more advanced programmers (not generally the same people as very few students come knowing, for example, C, but Visual Basic is common), do tend to use the Shell more when debugging the more substantial problems.
We do seem to be having some trouble with the inconsistency of writing to stdout and file. To make things easier early on we have them write to screen using the print command. They can then separate abritrary variables using commas. However then they do fout.write(myfloat, myint, "Some numbers") and it doesn't work they get confused. It may be better to teach them to write to screen using sys.stdout.write from the start as that then provides a consistent writing tool.
Point taken. It's just that sys.stdout.write is so cumbersome to produce neat-looking output. :-(
Indeed. I can just imagine how terrifying ``Hello World'' would look to our students (many of whom currently hate and avoid programming at all costs) with a printf statement. Most of them are happy with formatted output by the end of the day though.
I wonder what could be done to fix this? Making write() act more like print is impossible for backwards compatibility reasons (separate print calls always insert a space or a newline between data, and separate write() calls do neither).
That was going to be my suggestion, but fair enough.
Maybe we should add a file method
f.printf("format string", args)
How about a file method f.print(arbitrary comma separated variables) that works in the same way as print?
and a built-in function
printf("format string", args)
and deprecate the print statement???
Deprecating the print statement is, I think, an unecessarily big change to the language. This trivial method of writing, that does all sorts of voodoo to format intelligently is one of Python's strongest features. Perhaps a printf should be included though -- students learning Python would then have another skill applicable to C. Part of the political resistance I'm experiencing seems to be related to the fact that Python does so much for you--print being a particular example of this. -- Michael
In the handbook we insist they use the Shell only once (for the ``hello world'' program). Perhaps we should have them use it for a little longer.
The standard tutorial uses the Python shell extensively, to show how various language constructs work. Maybe you can borrow from there.
Interestingly, the experienced UNIX users and more advanced programmers (not generally the same people as very few students come knowing, for example, C, but Visual Basic is common), do tend to use the Shell more when debugging the more substantial problems.
Makes sense -- interactive debugging is a very powerful tool.
Maybe we should add a file method
f.printf("format string", args)
How about a file method f.print(arbitrary comma separated variables) that works in the same way as print?
Alas, print is a keyword and can't be reused as a method name.
and a built-in function
printf("format string", args)
and deprecate the print statement???
Deprecating the print statement is, I think, an unecessarily big change to the language. This trivial method of writing, that does all sorts of voodoo to format intelligently is one of Python's strongest features.
Ah, I must've suffered from temporary memory loss! In Python 2.0 and later you can use the print statement to write to a file, using print >>f, var, var, ... So forget about my suggestion of adding printf(). --Guido van Rossum (home page: http://www.python.org/~guido/)
Input of whitespace separated numbers from file or stdin is relatively
complex in Python:
line = raw_input() snumbers = string.split(line) x, y = float(snumbers[0], snumbers[1])
unless I'm missing something obvious. The comparable expression in Pascal is
readln(x, y)
True, more complicated, as per previous thread. def readln(): # defined once return [eval(i) for i in raw_input().split()] x,y = readln() # used elsewhere is a quickie workaround. Seems if your goal is to get right to Physics and not master Python as a language per se (i.e. Python is very much a means to an end), then you could teach students to go: from courseware import * at the top of their programs. Inside of this module could be included various shortcuts of this nature (e.g. readln). This might save time better spent on physics. In other words, code up to a higher, yet more specialized level, and use this customized API in class (the module might well include some routines for Numeric and GnuPlot stuff). Kirby
On Thu, May 30, 2002 at 09:13:39AM -0400, Kirby Urner wrote:
Seems if your goal is to get right to Physics and not master Python as a language per se (i.e. Python is very much a means to an end), then you could teach students to go:
from courseware import *
at the top of their programs. Inside of this module could be included various shortcuts of this nature (e.g. readln). This might save time better spent on physics. In other words, code up to a higher, yet more specialized level, and use this customized API in class (the module might well include some routines for Numeric and GnuPlot stuff).
We already have such a library that imports some functions for printing programs and output, and the appropriate Numeric and Gnuplot objects. If we found a satisfactory way of simplifying the kind of input we want to do this is precisely where it would go. As you say, we're in the business of teaching Physics (and programming for Physics) and not Python. Our main concern is getting a consistent input and output model from both stdin/out and file. The string.split() method isn't appallingly complex and is by no means a show-stopper, so if it turns out that using it increases student's understanding of what is going on by making everything more consistent we may stick with that. -- Michael
We already have such a library that imports some functions for printing programs and output, and the appropriate Numeric and Gnuplot objects. If we found a satisfactory way of simplifying the kind of input we want to do this is precisely where it would go.
Great minds think alike I guess :-D. Speaking of physics, you've no doubt checked into VPython, orginally developed to support study of physics using real time graphics routines at Carnegie-Mellon Univ, as I understand the history: http://www.vpython.org/ Seems to me the interface between physics and programming is becoming richer (and yet more affordable) by the day. Makes me nostalgic for life as an undergraduate (except in my day we had few PCs, no Linux, and no Python -- but I've got all that now, and a day job to boot). Kirby
On Wed, 2002-05-29 at 18:47, Ingo Linkweiler wrote:
are you using python for teaching programing?
Please see the "Who teaches Python" page at: http://www.ibiblio.org/obp/pyBiblio/schools.php As you find schools not listed on the page, I would be grateful if you could send them my way. I would like to keep this list as complete and up to date as possible to facilitate general communication (and aid in inquiries like yours ;-)
I am just writing a diploma paper about python and want to know your experiences with python.
What do you like when teaching python? For example: - Easy readable syntax - High Level language - Lists, Tupels, Dictionaries included - interpreter: Everything can be tested - Many tools available .....
AND MORE IMPORTANT: What are your problems with python? Are pupils/students having any problems or often asked questions? What do you dislike at python?
For example: - When teaching C or Pascal, newbies do not know, where to set a ";" and
where not. Any similar problems with Python? - Why must I set a ":" after "if" or "for" ? " if x == y : " .....
I've written two papers about the Yorktown High School experience with Python. They can each be found on my homepage: http://www.elkner.net I would like to hear back from you regarding the results of your inquiry. It would be great if we could include them on the pyBiblio site. jeff elkner yorktown high school arlington, va
Ingo Linkweiler wrote:
Hello,
are you using python for teaching programing?
Yes, I have used it over the last year for two middle school computer clubs (6th graders - 8th graders) that meet once per week for an hour after school. I have written a handout (~60 pages) which the club sessions have let me classroom test and I am in the process now of revising it based on the year's experience for use with next year's computer clubs.
I am just writing a diploma paper about python and want to know your experiences with python.
What do you like when teaching python?
My main attraction for trying Python this year instead of Perl (which I had done for several years previously) was the clarity of the object-oriented approach that presents itself in Python as compared to that in Perl where it is more buried and requires more of a stretch to understand clearly what is going on. I thought it was important to give the kids more experience with object-oriented programming since they are likely to see so much of that later if they go on in computing.
AND MORE IMPORTANT: What are your problems with python?
No particular problems. The integration with Tk (as exemplified by the bundle that includes both on the CD that comes with the O'Reilly Learning Perl book is particularly helpful. It isn't that I am a fan of Tk -- any gui is fine -- it's that it is a smooth install to get both so that there is less complication in getting staff to install it on the school's computers.
Are pupils/students having any problems or often asked questions?
No, they seem to have done fine. One girl extended the adventure game template I wrote for them to try to adapt so that it let the characters move Northwest, Southwest, Northeast, and Southeast in addition to NESW. Mainly, she did a cut and paste job but she was successful at it--including introducing bugs and figuring out what the problem was and fixing them. Of course, she was pretty experienced having taken Perl from me two years earlier when she was in sixth grade.
What do you dislike at python?
Nothing particularly. It's fine. Perl's fine. They all have their uses. The great thing about teaching either to 6th, 7th, and 8th graders is that they have no context in which to interpret things so they don't buy into religious wars about Perl vs. Python vs. Visual Basic vs. C++ vs. Unix vs. Windows. So, I try to avoid communicating my hang-ups to them in an effort to stave off yet another generation of religious wars about those subjects. For them, it's all about making the computer do something and it doesn't matter to them much which it is.
I hope you have many suggestions.
Good luck with your studies and survey. --David -- Dr. David J. Ritchie, Sr. djrassoc01@mindspring.com http://home.mindspring.com/~djrassoc01/
Ingo Linkweiler wrote:
What do you like when teaching python?
My answers are related to the course that my colleague Katja announced yesterday - http://www.pasteur.fr/recherche/unites/sis/formation/python/. The course is intended for bioinformaticians, most of them having learnt either perl, C or Scheme. The last time we taugth this course, it was a 5 half-days course (we did not have the time to do the whole course contained on the support, which would need at least 1 full-time week). ------------------------------------------
- Lists, Tupels, Dictionaries included
This is very important in bioinformatics. You have to manipulate strings, lists and dictionaries all the time. Biomolecules are indeed represented as string of characters: 'atgaagattttgatacttggtatttttctgtttttatgtagtacccc' but you spend your time converting them into lists or and back into string, etc, ... Also, the possibility to define the [] operator with __getitem__ is fantastic. In Biopython (www.biopython.org), they have defined dictionaries for all big genomic databases, so that by issuing a: GenBank['HUMCERP'] you fetch a db record from the Web server of the NCBI... Just one detail which makes things a little difficult. As I said, one very often has to change strings into lists and back to string in bioinformatics. To our knowledge, the only way to do this is with a type converter: l = list(s) then to get the list back (why is it that join is in strings and not in lists?): string.join(l) I don't know how to make this easier, but the difficulty seems to be in the fact that there are both object methods (join) and operators (len(), list(), str(),...). A solution could be to have some syntactic sugar to call the operator when the function is called as a method, e.g: l = s.list() would call list(s), or at least, the split method should accept "" separator: l = s.split("") which outputs: Traceback (most recent call last): File "<stdin>", line 1, in ? ValueError: empty separator ------------------------------------------
- interpreter: Everything can be tested
This is very important! Some problems in the interpreter: - copy&paste of several lines sometimes does not work - the interpreter should accept a command not exactly beginning at the exact position:
command when it's a single command. When you enter (by cut&paste) command or: command it does not work. I know it is related to the indentation problem, but for a beginner who already has difficulties, this is a cause of additional problems (ideally, a workspace as in Smalltalk would be marvellous - I haven't seen such thing in IDLE?).
Other suggestions: - the interpreter could keep an history of the commands *between* sessions. Every one does this: entering python, trying a module, exiting, re-entering python, re-trying... - the history could be at first indentation level. I.e, if you enter the definition of a whole function in the interpreter, doing a "previous command" with the arrow key should return the whole definition, as an editable buffer. [To give an example, I have built an [not exactly End-] User programming tool with and editor that you can use to redefine, save, print, debug, run, etc... a method, without saving it in a file - it's to program in XOtcl (www.xotcl.org) - see: http://www.pasteur.fr/~letondal/biok/Images/method-editor.gif] ------------------------------------------------------------------------------------
AND MORE IMPORTANT: What are your problems with python? Are pupils/students having any problems or often asked questions?
One big problem is the confusion between module names and inner component names. For instance, when you define a module in a file, say, Dna.py, which defines a class Dna, you have to do a: from Dna import Dna if you want to create Dna objects with: dna = Dna() or you have to say: dna = Dna.Dna() I know this is completely coherent, and we spent as much time as needed until they understood the mechanism, but this was really a major difficulty.
What do you dislike at python?
I like very much Python for clean and simple object-oriented programming. What I dislike: - self being mandatory in parameters list - no super() method call to call to super-class (AFAIK) - incremental and dynamic definition of class methods (I know you can do this by modifying the dictionary) (items which are probably already in a FAQ) -- Catherine Letondal -- Pasteur Institute Computing Center http://www.pasteur.fr/~letondal
- no super() method call to call to super-class (AFAIK)
In Python versions previous to 2.2, this could be done with the __bases__ attribute: ###
class Parent: ... def sayHello(self): ... print "hello" ... class Child(Parent): ... def sayHello(self): ... print "My mom says:", self.__class__.__bases__[0].sayHello(self) ... p, c = Parent(), Child() p.sayHello() hello c.sayHello() My mom says: hello ###
but as you can tell, this is really awkward! Multiple inheritance, combined with the dynamic features of Python (__getattr__/__setattr__), can complicate things. Python 2.2 has a new "super()" function that simplifies this a lot. With super(), the example above looks like: ### class Parent(object): def sayHello(self): print "Hello!" class Child(Parent): def sayHello(self): print "My mom says", super(Child, self).sayHello() ### See: http://www.python.org/doc/current/whatsnew/sect-rellinks.html for details on this new function. Hope this helps!
###
class Parent: ... def sayHello(self): ... print "hello" ... class Child(Parent): ... def sayHello(self): ... print "My mom says:", self.__class__.__bases__[0].sayHello(self) ... p, c = Parent(), Child() p.sayHello() hello c.sayHello() My mom says: hello ###
but as you can tell, this is really awkward!
It is also wrong. Consider
class GrandChild(Child): pass ... g = GrandChild() g.sayHello() (infinite loop)
--Guido van Rossum (home page: http://www.python.org/~guido/)
On Fri, 7 Jun 2002, Guido van Rossum wrote:
###
class Parent: ... def sayHello(self): ... print "hello" ... class Child(Parent): ... def sayHello(self): ... print "My mom says:", self.__class__.__bases__[0].sayHello(self) ... p, c = Parent(), Child() p.sayHello() hello c.sayHello() My mom says: hello ###
but as you can tell, this is really awkward!
It is also wrong. Consider
class GrandChild(Child): pass ... g = GrandChild() g.sayHello() (infinite loop)
Doh. Let me try that one more time. ### class Parent: def sayHello(self): print "Hello" class Child(Parent): def sayHello(self): print "My mom says:", Parent.sayHello(self) ### Thanks for the correction!
participants (8)
-
Catherine Letondal -
Danny Yoo -
Dr. David J. Ritchie -
Guido van Rossum -
Ingo Linkweiler -
Jeffrey Elkner -
Kirby Urner -
Michael Williams