Dethe Elza wrote:

...

.... Back to the subject of improved turtles, I think there could be a two-pronged approach. The first prong would be to provide incremental improvements to the existing turtle.py (and possibly IDLE) within the standard distribution... Along this prong, how about a list of turtle.py's deficiencies? I suspect this list will to a lot to assuage Art's fears of over- elaboration. What I have read in the discussion is that a clear small interface is wanted to the internal module.

Here are the problems I had with turtle.py in the situation of teaching it to ~500 first-year university students, most of whom identify themselves as non-technical. I've ordered them by importance for my purposes: - There's no doc strings or other documentation in the turtle.py module itself. There is one the web page, and that certainly helps, but it should be in turtle.py. - The error messages are sometimes unnecessarily confusing. For example, you can set pen colors in about three ways, and different kinds of errors are generated depending on the mistake you make. One standard error message that gives examples of the correct way to set colors would save a lot of unnecessary headaches. - Idle and Python don't play well together (on Windows, at least). There are fixes, but they are still not ideal. - I find the turtle too powerful for my purposes. Many of the current turtle functions can easily be implemented in terms of other ones, and I think it's instructive for students to do that for themselves, to learn about functional decomposition, bottom-up programming, code re-use, etc. - At the same time, I would also like to have more powerful turtles that would be useful for more powerful graphics. You know, the right turtle for the right job. :-) - The name Pen is a bit confusing, since this is "turtle" graphics. But it wasn't a major problem for me since I stuck mainly with the non-OOP turtle commands. One the plus side: - Once Python is installed, turtle.py just works (usually!). There's no extra packages to install or options to configure. Just load and go. Many students (and teachers!) get frustrated installing software at home, and the "batteries included" nature of turtle.py is a win. Dealing with installation issues can eat up a lot of time in large courses, and so minimizing that is good. - It's simple, easy to understand stuff that turns out to be very powerful. Even using multiple Pen objects proved easy for interested students when they see even one or two examples. (My course doesn't cover OOP, but after seeing the success of using turtle.py, it makes sense to move that way.) - It's in Python. Part of the goal of the course is, at least for a few students, to learn enough about Python to use it for practical, real-world scripting that don't involve graphics or games. So I prefer to stick to the language proper than to use special educational packages. Part of this is personal taste and the culture of my department's approach to introducing programming; I certainly do give students special libraries and other packages (like PyGame) later in the course, so I am admittedly "soft" on this issue, and possibly inconsistent. It boils down to this: turtle graphics was fun and educational for hundreds of students. I can't think of many other things I've done in such a class that have had such a positive impact. Fixing a few obvious problems with turtle.py will surely only improve the experience. Moving to a different kind of graphics or a different turtle system might work as well or better, but I am not currently convinced that such a move will accrue enough benefits to make it worth the effort. I know from experience the sort of risks involved in making changes to big courses. I agree with those who suggested a two-pronged approach: tweak turtle.py, and then consider the creation of bigger and better Python education tools. I've already written a lot fo doc-strings for turtle.py to offer to Vern, and I would willing to help out on the second prong too; if, for example, Gregor wanted to spearhead that starting with xturtle and friends, I'd be interested in helping out insofar as my particular experience and needs can be of use. Toby -- Dr. Toby Donaldson School of Computing Science Simon Fraser University (Surrey)