Mailman 3 March 2006 - Edu-sig

Monkeys! (was turtles)
by kirby urner 04 Mar '06

04 Mar '06

So with my 8th graders this week, we were back to writing a class. Here's the eventual definition: class Monkey: def __init__(self, name): self.name = name self.stomach = [] def eat(self, food): self.stomach.append(food) print "Yum, thanks for the %s" % food def __repr__(self): return "Monkey named %s" % self.name We didn't do this all at once, e.g. I had the self.stomach.append(food) line before I'd mentioned a stomach elsewhere and said this wouldn't work, because you couldn't append to a list that didn't yet exist. How to fix? My most advanced student raised his hand and gave the right answer: start with an empty list, and put it up top in the constructor. In my patter, I make sure to say words like "instantiate" and "object" a lot. I talk about classes as "blueprints" (like for a house) whereas what you actually "instantiate" from a blueprint, or plan, is an object, an actual house with its own color. Then each student created a bunch of Monkey objects, after saving the above in site-packages as zoo.py. >>> from zoo import Monkey >>> m1 = Monkey('BoBo') >>> m2 = Monkey('George') # as in Curious George At this point, I'd go around the room helping any student with broken code. Common errors: saved as Zoo.py but importing from zoo.py. Missing colon somewhere. Single under instead of underunder. Inconsistent indentation. Of course I'd talked about all of these possible mistakes in some detail, but kids sometimes tune out or are involved in other things. A couple tried to do all this in shell mode, instead of in a text window (I have them Save As zoo.py immediately, even with a blank slate, to get the color coding). A couple thought where I wrote 'name' they should substitute an actual name, like 'Andy' i.e. they were not yet clear on the difference between variable-as-storage and value. Actually, the first thing I did was put triple-quote comments up top, and talk about conventions of indicating alpha, beta and production-ready code. Kind of an interlude, story time. Anyway, back to the shell: >>> m1.eat('banana') Yum, thanks for the banana >>> m1.eat('coconut') Yum, thanks for the coconut >>> m1.stomach ['banana', 'coconut'] I asked what would be in m2's stomach and a chorus of voices gave the right answer: nothing yet, because only m1 had been fed. Then, as it was almost the end of the period, I had a brainstorm. Let's feed m2 to m1! >>> m1.eat(m2) Yum, thanks for the Monkey named George >>> m1.stomach ['banana','coconut','Monkey named George'] Hah hah. They thought that was pretty funny. Then I had m2 eat itself. OK that was just weird. Kirby is just Kirby I guess (yum). Next week, we'll be writing a more generic Mammal class and having our Monkey and Dog inherit from it. We'll also get more deeply into the Dictionary type (so far, I've only discussed lists, and strings in sum detail, including string substitution syntax). Once we have the dictionary type more understood, I'll be able to mention self.__dict__ and talk about how the individual "state" (e.g. the stomach) of each object (e.g. each Monkey) is saved in a dictionary. I like diving into OO pretty early, obviously. I'm not one of these "let's do procedural programming for a year and get around to OO only in year number two." No way Jose! Kirby

2 4

Re: [Edu-sig] Edu-sig Digest, Vol 32, Issue 8
by Toby Donaldson 03 Mar '06

03 Mar '06

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

1 0

Re: [Edu-sig] IDLE wish (was Edu-sig Digest, Vol 31, Issue 16)
by Radenski, Atanas 03 Mar '06

03 Mar '06

> What is the importance of having your improved module part of the standard distribution? The current turtle.py module it is already in the standard distribution. Why should not an *improved* version remain in the standard distribution? Quite a few instructors already rely on turtle.py being in the standard distribution. Turtle.py is good for beginners. Having it outside the standard distribution will create difficulties for beginner learners and their instructors. Atanas ________________________________ From: edu-sig-bounces(a)python.org on behalf of Arthur Sent: Fri 3/3/2006 7:40 AM To: 'Vern Ceder'; 'Arthur' Cc: edu-sig(a)python.org Subject: Re: [Edu-sig] IDLE wish (was Edu-sig Digest, Vol 31, Issue 16) > >-----Original Message----- > >From: Vern Ceder [mailto:vceder@canterburyschool.org] > >However if our discussion of the module bothers you that > >much, I'm happy to move it to off of this list. How about responding to some of my substantive points. Or are you saying you don't perceive any? Starting with: What is the importance of having your improved module part of the standard distribution? Why isn't the cheeseshop - http://cheeseshop.python.org/pypi - the appropriate place for results of your undertaking, as it is foe the results of every other Python application developer. Or is the substance of your response simply that I am in discussion with the Phone Company, have been put on hold, and am wasting my time in attempting to have a discussion on the merits. Are you an appointed or self-appointed redactor of all that is Turtle in the world of Python? Art _______________________________________________ Edu-sig mailing list Edu-sig(a)python.org http://mail.python.org/mailman/listinfo/edu-sig

1 0

PyLogo anyone?
by Daniel Ajoy 02 Mar '06

02 Mar '06

I find strange that PyLogo hasn't been mention in this discussion: Daniel Date: Tue, 18 Nov 2003 16:16:56 -0600 From: Ian Bicking ianb at colorstudy.com Subject: ANN: PyLogo 0.1 PyLogo 0.1 ========== This is the first public release of the still rough (but I think functional) PyLogo interpreter. PyLogo interprets the Logo language, an education Lisp-like language best known for its turtle graphics. Found at: http://pylogo.org Who Is This For? ================ This release is primarily targeted at other developers. Though PyLogo is a fairly complete Logo implementation, the programming environment is still rough. Because PyLogo is written in Python, this is a very easy interpreter to work with -- the code is small, it's easy to create new primitives using Python code, and there's already a wide array of interesting and useful Python libraries which are easily made accessible to Logo programs. It also inherits Python's rich object model (though it needs more work to make Python objects easier to work with), which makes it possible to avoid some of the more crude features of some Logo dialects with respect to properties (dictionaries), files, etc. What Does It Do Now? ==================== PyLogo implements all of the core Logo features (as far as I know), generally trying to match UCBLogo (the de facto standard Logo implementation). Like traditional Logo, it uses dynamic scoping and a global namespace. Unlike many young language implementation, the existence of bugs is given consideration -- errors produce tracebacks, and room exists for even more helpful error diagnostics. Turtle graphics are available, including multiple turtles. You can use multiple, concurrent threads in your Logo programs. (You can't use threads and turtles together -- yet) -- Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org ***************************** OpenWorld Learning http://www.openworldlearning.org

1 0

Re: [Edu-sig] 3D Logo
by Daniel Ajoy 02 Mar '06

02 Mar '06

On 1 Mar 2006 at 21:12, edu-sig-request(a)python.org wrote: > You mean with the -n switch? Why not just use some other language that's > better at Turtles than Python? is my main question. If you're going to use > Turtles as your primary pedagogy, I suggest Logo or some more sophisticated > 3D turtle implementation (there's a 3D Logo no?). Sure there is, I know three: http://zenon.superforos.com/viewtopic.php?p=50 Daniel ***************************** OpenWorld Learning http://www.openworldlearning.org

1 0

Any suggestions about turlte.py
by Vern Ceder 01 Mar '06

01 Mar '06

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(a)canterburyschool.org; 260-436-0746; FAX: 260-436-5137

3 4

Re: [Edu-sig] Edu-sig Digest, Vol 32, Issue 2
by Toby Donaldson 01 Mar '06

01 Mar '06

> 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 volunteer to help add doc-strings (with examples) to the code if you would like such assistance. > 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. One other source of ideas for graphics beyond turtles is the ACM Java Task Force, which has just released a new version of the proposed acm package: http://www-cs-faculty.stanford.edu/~eroberts//jtf/ Creating standard educational libraries like this for Python could be a real boon. Toby

1 0

Re: [Edu-sig] Edu-sig Digest, Vol 32, Issue 2
by Toby Donaldson 01 Mar '06

01 Mar '06

> > 1. The broken interaction between Idle and the turtle package. > > On windows, I have an icon linked to: > C:\Python24\Lib\idlelib\idle.pyw -n > Does this expedient not work for you? > > The -n means to use a single-process model (more fragile, > but the interaction of two GUI loops is not there). Thanks! I've never noticed this option before. Toby

1 0

Re: [Edu-sig] Edu-sig Digest, Vol 31, Issue 16
by Radenski, Atanas 28 Feb '06

28 Feb '06

My experience with turtle graphics in a CS1 course has been very rewarding. It allows *everyone*, not just the most motivated, to be creative. With turtle, drawing an original and intersting design is so easy. In a couple of dozens of lines, my CS1 students create some amazing designs - every semester brings more and more gems. Students use turtle to draw fractals and then concentric figures that change colors and are constantly redrawn. Of course, turtle is not fast and it is not fancy as programming, and it behaves badly in Windows, but the important thing is that it really inspires almost all beginners to learn and do more. My students post their turtle graphics designs in course Forums and they are so proud - for good reason. Consider for example this simple program: # Pattern Designer import turtle; # Create a blue pen and determine the window's width and height: def init(): pen = turtle.Pen(); pen.color(0, 0, 1); # blue width = pen.window_width(); height = pen.window_height(); return pen, width, height; # Given a number, design a pattern for that number: def pattern(number): pen, w, h = init(); # Switch off tracing for higher speed: pen.tracer(False); for x in range(-w/2, +w/2): for y in range (-h/2, +h/2): draw(pen, number, x, y); # Temporarily switch on tracing to observe drawing: if (x % 100 == 0): pen.tracer(True); pen.tracer(False); pen.tracer(True); # Draw a pattern element at point (x, y): def draw(pen, number, x, y): a = y * (number / 100.0); b = x * (number / 100.0); ez = int(a*a*a + b*b*b); # Try ez = int(a*a + b*b) and other expressions. if (ez % 2 == 0): pen.up(); pen.goto(x, y); pen.down(); pen.circle(1); # Draw pattern #5 pattern(5); # The above program is a framework to design original patterns that are different form anything else - just by playing with the draw function above. Change the expression that defines ez, use random numbers for colors, etc. The opportunities for creative designs are unlimited. Of course the above program is slow. But it delivers exciting designs and inspires people. This is what matters, particularly in CS1. Certainly, one can use more realistic platforms, such as VPython, but then the complexity will probably kill the enthusiasm. This is why I am interested in the turtle module and its improvement. (Thank you again, Vern.) Atanas Atanas Radenski mailto:radenski@chapman.edu <mailto:radenski@chapman.edu> http://www.chapman.edu/~radenski/ <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 ________________________________ From: edu-sig-bounces(a)python.org [mailto:edu-sig-bounces@python.org] On Behalf Of kirby urner Sent: Tuesday, February 28, 2006 5:10 PM To: Toby Donaldson Cc: edu-sig(a)python.org Subject: Re: [Edu-sig] Edu-sig Digest, Vol 31, Issue 16 On 2/28/06, Toby Donaldson <tjd(a)sfu.ca> wrote: 1. The broken interaction between Idle and the turtle package. 2. Poor documentation. To actually understand certain function calls, it was necessary to read the turtle.py source code. My tentative conclusion, reading the above, and from some personal experience, is the Tkinter turtle.py, while a fun demo, is mostly a toy and should not be used for serious teaching, at least on Windows. Too much adverse experience. Too much frustration. In general, Tk on Windows has a lot of problems -- I generally forsake IDLE and go to a command window, for good reason. IPython is an alternative (a good one -- once you get it working in Windows, which is very doable). I really don't think *any* kind of turtle graphics is essential to learning programming, although as I said, I think the approach is very viable and destined to last. I'm not "anti turtle". My own special interest is in going back to the very early days of Logo, when a physical robot was used. I'd rather have hardware robots than screen based ones, with Python bindings. SONY should seed me a prototype :-D Kirby

1 0

Re: [Edu-sig] Any suggestions about turlte.py
by Radenski, Atanas 28 Feb '06

28 Feb '06

Vern, My apologies for being unclear. In Windows, turtle commands in interactive mode have been most problematic, meaning that Tk becomes irresponsive. In Windows XP, this can be simulated very easily. 0. Launch IDLE and run a Python shell. 1. Launch IE Explorer and make sure it covers the Python shell. 2. Bring the shell to the front and enter: >>> import turtle; pen = turtle.Pen(); After this, Tk becomes unresponsive. In addition, I believe my students have had problems of the second type you refer to: when a window with an already completed drawing/program becomes unresponsive. Unfortunately, I could not recreate such a situation today. I do not think I have had problems with a turtle program that is *running*. I have found Turtle graphics very useful, despite of all difficulties in Windows. Even a partial improvement would be beneficial. To me it seems very important to keep the new turtle module as compatible as possible with the current one. The reason is the turtle module has already been used in various publications or internal teaching materials. It would be nice if the updated turtle can be used with existing resources. Again, thank you for doing this. Atanas Atanas Radenski mailto:radenski@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: Vern Ceder [mailto:vceder@canterburyschool.org] > Sent: Tuesday, February 28, 2006 5:49 AM > To: Radenski, Atanas; Edu-sig(a)python.org > Subject: Re: [Edu-sig] Any suggestions about turlte.py > > 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@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(a)python.org [mailto:edu-sig-bounces@python.org] > > > > On > > > >>Behalf Of Vern Ceder > >>Sent: Monday, February 27, 2006 11:32 AM > >>To: Edu-sig(a)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(a)canterburyschool.org; 260-436-0746; FAX: 260-436-5137 > >>_______________________________________________ > >>Edu-sig mailing list > >>Edu-sig(a)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(a)canterburyschool.org; 260-436-0746; FAX: 260-436-5137

1 0