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