Mailman 3 February 2006 - Edu-sig

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] Any suggestions about turlte.py
by Radenski, Atanas 28 Feb '06

28 Feb '06

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

2 1

Re: [Edu-sig] Any suggestions about turtle.py
by Vern Ceder 27 Feb '06

27 Feb '06

Brad, I agree on both counts. In fact my current implementation does the first already and I was just thinking today about doing the second. Thanks for the suggestions - I'm glad to hear I'm on the right track. Vern Brad Miller wrote: > Vern, > > Thanks for taking this on. I have my students implement a turtle class > as a programming assignment, but I also like to use turtle graphics for > some fun recursion problems. > > A couple of suggestions: > 1. Make Turtle an alias for Pen. I always find it weird that we are > importing the Turtle module but instantiating a Pen. > > 2. Have an option to make the turtle go fast. Its too slow for complex > stuff as it is. > > Brad > > > On Feb 27, 2006, at 1:31 PM, Vern Ceder wrote: > >> 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

Textbooks
by Peter Chase 27 Feb '06

27 Feb '06

Thanks to all for the discussion. I think I'm going with Zelle, with some Tk handouts for the graphics. Regards to all, Peter Chase Sul Ross State University

2 1

Re: [Edu-sig] SIGCSE 2006 - Special Session on Teaching with Python
by Brad Miller 27 Feb '06

27 Feb '06

On Feb 26, 2006, at 8:23 AM, Arthur wrote: > > Brad has been quiet about his publication > > > Problem Solving > with Algorithms > and Data Structures > Using Python > > Thanks for the plug. > http://www.fbeedle.com/053-9.html > > It's certainly of interest to me. > > Of course Alan Kay expressed this week that the teaching of > algorithms and data structures in CS is a problem: > > that: > """nothing exciting about computing today has to do with data > structures and algorithms""" (Kay being paraphrased at > > http://www.windley.com/archives/2006/02/alan_kay_is_com.shtml) > I don't know how accurate the paraphrasing is of what Kay said but the analogy doesn't work very well for me. To quote from the above link: One of Alan’s undergraduate degrees is in molecular biology. He can’t understand it anymore despite having tried to review new developments every few years. That’s not true in computer science. The basics are still mostly the same. If you go to most campuses, there is a single computer science department and the first course in computer science is almost indistinguishable from the first course in 1960. They’re about data structures and algorithms despite the fact that almost nothing exciting about computing today has to do with data structures and algorithms. I can go over and check with my biology colleagues tomorrow, but I'm pretty sure they still teach undergrads about molecules and cells in introductory biology. Sure the latest developments are hard to understand but I doubt they are being taught at the introductory level. Data structures and algorithms may not be exciting (for Kay), but they are as fundamental to computing as cells are to biology.

3 6

textbooks
by Christine A. Shannon 27 Feb '06

27 Feb '06

Let me just add a couple notes ... I have used Zelle's book for teaching and I think it is great. My students were doing some pretty exciting graphics by week three. One thing I like about it is its size. It has an appropriate amount of material for a single course and is clearly at the introductory level. I also have a copy of Chun's book "Core Programming" and I use it a lot for my own information. I have not used it as the text but have recommended it to many students who are looking for a more comprehensive text. I look forward to the next edition.

1 0

Re: [Edu-sig] Textbooks
by Daniel Ajoy 26 Feb '06

26 Feb '06

On 25 Feb 2006 at 20:01, edu-sig-request(a)python.org wrote: > Date: Sat, 25 Feb 2006 12:18:47 -0500 > From: "Paul Barrett" <pebarrett(a)gmail.com> > > The multidimensional array modules in their various incarnations, Numeric, > Numarray and Numpy - with the Numpy being the latest and hopeful last - are > based on J's array semantics and behaviour. So in some sense, you can teach > J programming concepts by using Numpy. > > Have you you tried Numpy? > > -- Paul Really_ can any of those tools be used to program tacitly? That is without the need to use variables (with the help of "forks", "hooks" and the like)? Daniel ***************************** OpenWorld Learning http://www.openworldlearning.org

4 6

Re: [Edu-sig] Programming in the Classroom
by Christian Mascher 26 Feb '06

26 Feb '06

Hi Kirby, > Given this is 8th grade, I look at it as first exposure or a first pass. > Some stuff will go over their heads, some will stick. It's not necessary > that they be complete masters of everything they see. I think a lot of > education is previewing. What I dislike about most math curricula is how > it's taboo to look ahead and see where we're going. "Looking ahead" is an underdeveloped strain in most curricula, I'm sure. It's partly in the (traditional use) of the word curriculum: a path from a defined outset to a well-defined goal. Given limited time and the pressure of written examinations teachers tend to shorten those interesting but time-consuming overview sessions in favor of more exercises (at least it happens to me often enough, learning _my_ lessons as a teacher, <sigh>). Another thing: Only an expert will be able to do a meaningful preview, so it's a lecture which mainly reaches the more interested students (who will appreciate it and learn from listening) but leaves the rest with nothing to _do_. So I don't think it is a taboo that these connections with future themes are understressed. It is just hard to do this right for larger audiences (classes). Still, I think you are right: It is a good thing to (quietly) stick in more than the linear curriculum stuff, even things which will go over their heads. I _am_ doing this here, for instance using the words 'object' or 'method' without "explaining it", only introducing a vocabulary through usage. On the other hand, I want to have a very clear picture in my head of _those_ ideas which will be spelled out step by step and which will be in the tests. > I understand the Sony robot dog has Python bindings but have no details. > Sony should send me a sample. :-D If they send samples, I want one too... ;-)) > I started out talking about types e.g. type(2), type(2.0) and > type('hello'). Thinking in terms of types makes plenty of sense, because > what Python provides is "an extensible type system" i.e. you get the > primitive types out of the box, then you build your own, adding to the types > ( = classes) available. Having looked at smalltalk (squeak) a little in the past year: in this aspect Python is not nearly as uniform (difference between primitive types/user classes) as smalltalk is. I understand that much work is going on to address this issue... > I use a projector, boost IDLE to like 20 point (Comic Sans > these days) and have kids follow along at their own workstations as I > "doodle" i.e. write simple functions and stuff. Other times I hand out > stuff on paper and walk around the room, helping where needed. I often use the projector in exactly the same way (apart from the Comic Sans, will try that out next time) > I continue to think programming is a very motivating way to get into > mathematics. Yes. And Python together with Idle (doodling up functions) is a wonderful tool. > In the pre-college years, I wouldn't be unhappy to see > programming move into the foreground. To make it sound radical and provoke > anxiety, I'd say my position is: drop math completely as traditionally > taught, and teach computer science instead -- but in a different way that > preserves most of the old math content (plus adds a lot of new stuff). I could imagine that, too. But in a centralized school system it doesn't look like anything like this is going to happen here soon. > A > less radical position: offer this as an alternative "track" running in > parallel and let it compete with traditional math. That's actually a > crueler option (means slow death of traditional math vs. a quick transition > to these better methods). In our system pupils are obliged to choose an optional subject (with 3 lesson-hours a 45 min per week) in grade nine and ten. This can be another foreign language or a combination like biology/chemistry or maths/computer. The latter is chosen rather often with different motivations: a) I like playing around with computers ('cause I like computer games) and it sounds less dull and less hard than, say French b) Computers will be important in a later professional life (often the parents' view) c) I like maths and want more of that So some have this on top of their regular maths-class (also 3 lesson-hours per week). Although many have chosen it with motive a) rather than c) I think one can say that all profit from getting exposed to more maths. (Nearly all of them will go on to high-school-level later, where maths (calculus, vectors, probability) is obligatory for everyone.) I can't help but think that 3 weekly lesson-hours (from around 32) for maths is not enough. The German system has always promoted _many_ different subjects at the same time on the grounds that only general education is the goal of the schools. I liked this as a pupil (with many different interests). But as a teacher I feel that today just too many pupils get only very superficial bits of knowledge here and there. Zapping through school subjects like checking through 30 TV channels. Concentrating hard on less subjects could turn out to be more educating. Cheers, Christian

1 0

SIGCSE 2006 - Special Session on Teaching with Python
by Brad Miller 26 Feb '06

26 Feb '06

The last note about the Python in Education BOF at PyCon inspired me to send this out. John Zelle, Mark Guzdial, David Ranum, and myself will be hosting a special session on teaching introductory computer science with Python at SIGCSE this week. I hope that this will be an opportunity to meet some of you folks on the list face to face and have some great discussion about teaching with Python. Hope to see you there! Brad -- Brad Miller, PhD Assistant Professor Luther College http://www.cs.luther.edu/~bmiller jabber: bnmnetp(a)jabber.org

2 1

Textbooks
by Peter Chase 26 Feb '06

26 Feb '06

I'm teaching some prospective K-12 teachers this summer and propose to introduce them to Python. Reasons are numerous - It's the least weird language I know. - It offers so many programming styles. - And not least, it's free SO: Any recommendations as to course textbooks? Or just go with Zelle and/or O'Reilly's latest wood rat book? - The students presumably have had programming courses already. - I would think that K-12 students would be happier if they could generate some graphics. - This is a 6-weeks course. Little leisure time. Appreciate any advice. Peter Chase Sul Ross State University

10 16