[Edu-sig] suggetions abaout turtle.py

Gregor Lingl glingl at aon.at
Wed Mar 1 04:28:20 CET 2006


Vern Ceder schrieb:
> Hello everyone,
> 
> As a consequence of my complaining about it in my PyCon talk, I have 
> been invited to submit some patches for turtle.py. To my mind, turtle.py 
> should be something that one could actually use for some very simple 
> "programming with graphics" lessons, with NO tweaking or additional 
> software.

Hello all,

I'm very happy, that this topic is coming up. In my opinion turtle 
graphics is a very valuable tool for learning (and teaching) 
programming. That is the reason, why I chose turtle graphics as the 
basic tool in my textbook "Python für Kids" (written in German), 
although I felt, that Python's turtle.py was rather limited. In my book 
I tried (imho successfully) to introduce nearly every programming 
concept by visualizing it via turtle graphics. Of course there are many 
other ways to to that, but this is definitely one, which one can go.

In the meantime (and looking forward to preparing a second edition
of my book) I've been working on a new turtle graphics module - I named 
it Xturtle.py.

My main intention was just to achieve what Vern Ceder wrote in the lines 
above:

 > "programming with graphics" lessons, with NO tweaking or additional
 > software.

My main inspiration was the turtle graphics component of Logo
(specifically of MSW-Logo).

So I'd like to participate in the development of this amended tool.

What I can offer for now is the following:

Consider Xturtle.py as a proposition about what a turtle module could
comprise. So have a look at the functions it provides and at examples
done with it. It is *NOT* intetended as final result but only as a 
prototype - but a prototype which had been in use with numerous classes 
and students since two years and really showed up very few bugs.

I'm currently doing a complete rewrite, which - in fact - I intended to
offer to you slready before this thread started up. I think it will take 
two more intensive coding weekends until I'll come up with a "pre alpha 
release".

In the meantime

1) I submit my Xturtle.py module along with a set of 10+ demo samples.
I've zipped them into a package and I'll try to submit them as
an attachment in a separate follow up posting.

Moreover the zipped package XturtlePkg.ZIP as well as the single files 
can be downloaded from

http://ada.rg16.asn-wien.ac.at/~python/Xturtle/

The README.TXT, which mainly contains a description of the sample 
programs, will be attached to this posting.

Of course I'd like to get feedback from those of you, who find turtle 
graphics useful for teaching, but ALSO FROM THOSE OF YOU, who "don't 
think *any* kind of turtle graphics is essential to learning".

I'd like to stress, that there now is an effort to produce a valuable 
teaching tool, which should be done as well as possible. Nonwithstanding 
the fact, that not all who teach Python will use it, nor those, who will 
use it, will use it in the same way. Moreover let's remember, that 
turtle graphics was invented to teach programming to very young people.
So let's do it in a way, that interesting things can easily be done with it.

2) When thinking about a renewed turtle.py, there come up a lot of
points to discuss - especially in the early stage of development.
(Considering the fact, that here in Europe it's 3:30 in the morning, 
I'll only will touch a few of them)

(a) How about compatibility? Should every old turtle program  be 
executable with the amended module? Remind that there is some
strange behaviour in the old module concerning fill. IMO it should be 
discussed if the "radians"-mode in turtle.py should be retained. (Is it 
really useful?)

(b) The problem of the "hanging turtle". This was introduced with Python 
2.3 when IDLE was renewed. There exist at least to possible "solutions":
(a) to use IDLE with the -n switch whenever *interactive* turtle 
graphics is needed. This is rather easy, as opening IDLE for editing a
given Python program (at least under Windows) opens it automatically in 
this -n - switch - mode. I for my part work with two different links to
IDLE on my desktop, normal mode and "no subprocesses" mode, also in my 
classes.
(b) one could try to use the approach of John Zelle, which he did in his
graphics package, namely to let the drawing do in a separate thread. I 
don't know if this is easily possible with the animated drawing turtles
- perhaps one should produce a prototype to see ... (Guido two or three 
years ago told me, that Tkinter is not threadsave)
(c) I'd propose to add a sort of TurtleCanvas class to the turtle 
module. (You will observe that Xturtle works with a scrolled canvas due 
to a comment in the source code of good old turtle.py, which asked for 
that ;-) ). There are simply several canvas oriented commands (like 
setbg etc.) To implement them as Pen (= Turtle)  methods doesn't make 
sense. Also resizing the canvas would be a useful candidate (?).
(d) I'll add one more question as an example:
turtle.py has the function width() which sets the thickness of the lines 
to draw. There is no function to "get" it.
In Xturtle.py I've implemented pensize() (with width() as an alias) in a 
  way thatit can be used to set the pensize, when called with an 
argument and to return the current pensize when called without arguments.
Would you like this or would you prefer get- and set- functions() for 
each property? What is the "more pythonic" way?
There are many functions concerning pen-properties where this problem 
arises. They should be treated uniformly.


I'll close for now. Only a few remarks to the following:
> 
> So I think the following would be handy:
> 
> 1. equally usable with either "import * from turtle" or "import turtle" 
> imports

I think this is possible currently . What do you meadn exactly?
Something like "from turtle import Pen"?
> 2. should open with a window covering at least half the screen (the 
> current default is too small to be useful)
Xturtle.py does so
> 3. should offer some simple configuration choices for things like 
> initial size and shape, but mostly rely on reasonable defaults
ok, easy to do
> 4. should offer a class wrapper so that that one could easily 
> instantiate different turtles for a first experience with objects.
I don't understand this question. Currently there are the classes
Pen and RawPen in th turtle module. The anonymous turtle is in fact
an instance of Pen (named _pen). It is easy to uses several turtles  at 
the same time.
> 5. some minor tweaks to make it better behaved when run from IDLE
I fear, these will become major tweaks ...
> Does anyone have any feedback on these ideas or any other suggestions 
> about how turtle.py might be improved without being fundamentally changed?
> 
> Note: this is about turtle.py only, for all its deficiencies. Any 
> suggestions to try another library, system, or language will be 
> cheerfully, but resolutely, ignored. ;)
OK - Xturtle uses no other library, system nor language - so please
do not ignore it - not even resolutely ;-)

Regards
Gregor

P.S.: Xturtle is here, along with its example programs:

http://ada.rg16.asn-wien.ac.at/~python/Xturtle/


> 
> Cheers,
> Vern Ceder
> 
> 

-- 
Gregor Lingl
Reisnerstrasse 3/19
A-1030 Wien

Telefon: +43 1 713 33 98
Mobil:   +43 664 140 35 27

Website: python4kids.net
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: README.TXT
Url: http://mail.python.org/pipermail/edu-sig/attachments/20060301/f25e56a1/attachment.asc 


More information about the Edu-sig mailing list