[Edu-sig] Python @ Education: What are your problems?
Thu, 30 May 2002 14:30:30 +0100
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!
> 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?
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
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.