Re: [Edu-sig] suggestions about turtle.py

2006-02-28 Thread Vern Ceder
Everyone,

It seems that many of us (probably to our mutual surprise) have use for 
the humble turtle.

I want to get an improved, backward compatible patch into the standard 
package fairly soon, so over the next few days I will see if I can't 
come up with something that covers most of the ideas suggested here, 
including Gregor's libraries to some extent. I will of course post it 
for comments/testing before I send it along.

I would also suggest that those of us who are interested in turtle 
graphics consider what we want (even IF we want) in an extended turtle 
package as well, and how much we would want to push for its inclusion in 
the standard libraries.

My sense is that some of us will be fine if the basic turtle.py is 
usable, but others will really want more. Figuring out the "what" and 
"how much" may take some time. Certainly Gregor's Xturtle package will 
give us some direction in thinking about it.

Cheers,
Vern

Gregor Lingl wrote:
> 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 i

Re: [Edu-sig] suggestions about turtle.py

2006-03-01 Thread Christian Mascher

Hi all,

some years ago I had to teach using a macintosh lab: due to some 
problems with Tk on mac there was no Idle (and no turtle.py IIRC). That 
was when I realized how useful the "batteries included" Idle (-n) 
together with the old turle.py really was for me. It is my standard 
"graphics package".

I once used it to demonstrate the adding up of arrows for physics 
(arrows representing sine-waves with different phases like from a 
grating): you could script this from idle and look at the different 
resulting amplitudes for different angles (arrow spirals curling up or 
not). Physicists will know what I mean. A Turtle was exactly the right 
tool to do this.

As a quick way to introduce loops etc. with visual feedback the turtle 
has always worked out well in my (school) classes: ages 15-17.

I also like it that the old turtle.py lets you decide if you want to do 
it procedural (module-level functions) or OO-like. And if you want to 
hide the things you don't need or rename methods etc. just implement an 
appropriate intermediate module with your favorite settings and put it 
in the pythonpath for the class to import:

# ooTurtle.py
from turtle import Pen
class Turtle:
def __init__(self, mycolor='black'):
self._pen=Pen()
self.color(mycolor)
def color(self,*args):
self._pen.color(*args)
...

So dir(Turtle) will only show the methods you explicitly put in there. 
And you can have the names that you want.

Gregor Lingl wrote:
> 
> 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.

BTW, I like your book.

> 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.

Great stuff.

 > 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.

Still: "young" could be quite old. I still like to play around with 
turtles...

> (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?)

As I could rename methods (i.e. to German) anyway, backwards 
compatibility isn't that important. I just need to find the things I 
need. Fixing things to go with a new turtle-module shouldn't be 
difficult. But there should always be an Out-of-the-Box turtle in the 
standard installation.

> (c) I'd propose to add a sort of TurtleCanvas class to the turtle 
> module. 

Seems reasonable to me.

Just my 2c.

Cheers

Christian

___
Edu-sig mailing list
Edu-sig@python.org
http://mail.python.org/mailman/listinfo/edu-sig


Re: [Edu-sig] suggestions about turtle.py

2006-03-04 Thread Scott David Daniels

Just for fun I stole some of the turtle code, added docstrings, used
complex as position format, and made a small (but not entirely minimal)
turtle class.  I figured this might do as a straw-man for Myrtle the
Minimal Turtle.  I do like Christian Mascher's idea of making a turtle
with a contained Pen being how to control all of the "dir()" results.

--Scott David Daniels
[EMAIL PROTECTED]
# $Id: myrtle.py 1.3 2006/03/04 22:54:25 daniels Exp daniels $
'''Myrtle the minimally complex turtle'''
from math import sin, cos, tan, pi, atan2
import Tkinter

__version__ = '0.3'
__all__ = 'Turtle pi'.split()

class Turtle(object):
_root = None
_canvas = None

def destroy(self):
'''Wipe out evidence of where the root and canvas are'''
root = self.canvas._root()
if root is self._root:
self.__class__._root = None
self.__class__._canvas = self.canvas = None
root.destroy()

def __init__(self, canvas=None, root=None):
'''Make a turtle, and a canvas pen for it to play in (if necessary)'''
# Make a canvas (and a root) if necessary, record root.
if canvas is None:
if root is None:
if self.__class__._root is None:
self.__class__._root = root = Tkinter.Tk()
root.wm_protocol("WM_DELETE_WINDOW", self.destroy)
root = self.__class__._root
if self.__class__._canvas is None:
canvas = Tkinter.Canvas(root, background="white")
canvas.pack(expand=1, fill="both")
self.__class__._canvas = canvas
canvas = self.__class__._canvas
elif self.__class__._root is None:
if root is None:
root = canvas._root()
self.__class__._root = root

self.canvas = canvas# The canvas playpen for our turtle
self.items = [] # things showing on canvas
self.tracing = True # moving in little increments
self.arrow = 0  # The visible manifextation of the Turtle
self.reset()# Set other things up

def reset(self):
'''Erase the canvas and place the turtle in the center'''
self.canvas.update()# Make sure canvas is up-to-date
# Find current window sizes, and set origin and position at center
self.position = self.origin = self.window_dimension() * .5
# Set step-scaling and direction to right, 8 pixels
self.heading = complex(8.)
self.drawing = True # False for Pen-Up operation
self.width = 1  # width of the line the turtle leaves behind
self.ink = "black"  # color of ink Turtle currently wielding
self.filling = 0# polygon (1), smooth (-1), or non-fill modes
self.path = []  # Track of positions for use by fill modes
self.clear()
self.canvas._root().tkraise()  # Pop turtle's canvas to top-o-screen

def window_dimension(self):
'''Get the width and height of the canvas'''
width = self.canvas.winfo_width()
if width <= 1:  # the window isn't managed by a geometry manager
width = self.canvas['width']
height = self.canvas.winfo_height()
if height <= 1: # the window isn't managed by a geometry manager
height = self.canvas['height']
return complex(width, height)

def clear(self):
'''Drop all known elements from the canvas'''
self.fill(False)
for item in self.items:
self.canvas.delete(item)
self.items = []
self.hide()
self.show()

def fill(self, flag):
'''Fill path so far, then 0: no fill, 1: polygon fill, -1: smooth 
fill'''
if self.filling:
if len(self.path) > 2:
# can't create filled anything with less than 2 points
path = [(p.real, p.imag) for p in self.path]
item = self.canvas._create('polygon', path,
   dict(fill=self.ink,
smooth=self.filling < 0))
self.items.append(item)
self.canvas.lower(item)
self.path = []
self.filling = flag
if flag:
self.path.append(self.position)
self.forward(0)

def show(self, position=None):
'''Make the turtle visible (if tracing)'''
if self.tracing:
if position is None:
position = self.position
back = position - 2 * self.heading
self.hide()
self.arrow = self.canvas.create_line(back.real, back.imag,
position.real, position.imag,
width=self.width,
arrow="last",
capstyle="round",