[Edu-sig] Any suggestions about turlte.py

Vern Ceder vceder at canterburyschool.org
Tue Feb 28 14:49:03 CET 2006


Atanas,

Thanks for the input - I wasn't aware of the first problem you mention. 
I'm not sure about the secnond issue - do you mean that a turtle program 
that is *running* will hang if covered by other graphics? Or that a 
window with an already completed drawing/program will become 
unrresponsive? I've seen the second behavior, but not the first.

Thanks,
Vern

Radenski, Atanas wrote:
> Hi,
> 
> Thank you for taking care of the turtle.py module. Here are tow
> suggestions.
> 
> [1] I would suggest a correction of a bug in the fill function of
> turtle.py. The statement:
> 
>               # self._canvas.lower(item)
> 
> should be removed. As it is now, it lowers polygons when filled. This
> causes inconsistent behavior because nothing else is lowered. Here is a
> suggested the statement in context:
> 
> 
>     def fill(self, flag):
>         if self._filling:
>             path = tuple(self._path)
>             smooth = self._filling < 0
>             if len(path) > 2:
>                 item = self._canvas._create('polygon', path,
>                                             {'fill': self._color,
>                                              'smooth': smooth})
>                 self._items.append(item)
> 
>                 # Should be removed, because 
>                 # nothing else is lowered but filled polygons:
> 
>                 # self._canvas.lower(item)
> 
>                 if self._tofill:
>                     for item in self._tofill:
>                         self._canvas.itemconfigure(item,
> fill=self._color)
>                         self._items.append(item)
>         self._path = []
>         self._tofill = []
>         self._filling = flag
>         if flag:
>             self._path.append(self._position)
>         self.forward(0)
> 
> [2] A nuisance with this otherwise quite useful module is its behavior
> in Windows systems: It tends to *stop responding*. This happens when the
> canvas is covered by other graphics for a while, especially in cases
> when execution is triggered form the interactive prompt. It would be
> great if this problem can be fixed (although I am not sure what can be
> done about it.)
> 
> Atanas
> 
> Atanas Radenski      
> mailto:radenski at chapman.edu      http://www.chapman.edu/~radenski/
>  
> I find television very educating. Every time somebody turns on the set,
> I go into the other room and read a book - Groucho Marx
> 
> 
> 
>>-----Original Message-----
>>From: edu-sig-bounces at python.org [mailto:edu-sig-bounces at python.org]
> 
> On
> 
>>Behalf Of Vern Ceder
>>Sent: Monday, February 27, 2006 11:32 AM
>>To: Edu-sig at python.org
>>Subject: [Edu-sig] Any suggestions about turlte.py
>>
>>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.
>>
>>So I think the following would be handy:
>>
>>1. equally usable with either "import * from turtle" or "import
> 
> turtle"
> 
>>imports
>>2. should open with a window covering at least half the screen (the
>>current default is too small to be useful)
>>3. should offer some simple configuration choices for things like
>>initial size and shape, but mostly rely on reasonable defaults
>>4. should offer a class wrapper so that that one could easily
>>instantiate different turtles for a first experience with objects.
>>5. some minor tweaks to make it better behaved when run from IDLE
>>
>>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. ;)
>>
>>Cheers,
>>Vern Ceder
>>
>>
>>--
>>This time for sure!
>>    -Bullwinkle J. Moose
>>-----------------------------
>>Vern Ceder, Director of Technology
>>Canterbury School, 3210 Smith Road, Ft Wayne, IN 46804
>>vceder at canterburyschool.org; 260-436-0746; FAX: 260-436-5137
>>_______________________________________________
>>Edu-sig mailing list
>>Edu-sig at python.org
>>http://mail.python.org/mailman/listinfo/edu-sig

-- 
This time for sure!
    -Bullwinkle J. Moose
-----------------------------
Vern Ceder, Director of Technology
Canterbury School, 3210 Smith Road, Ft Wayne, IN 46804
vceder at canterburyschool.org; 260-436-0746; FAX: 260-436-5137


More information about the Edu-sig mailing list