Mailman 3 November 2006 - Edu-sig

Python for Halloween
by kirby urner Oct. 21, 2007

Oct. 21, 2007

Something about using 'ghost' in place of 'self' in a Shell class (allusion to anime as well). Maybe I did something like this last year (having deja vu again). But I'm realizing edu-sig is no longer a preferred venue for my curriculum writing. I'd rather huddle with MIT, Bruce Sherwood, Alan Kay and play *against* Arthur's team. Arthur, you make too many enemies too quickly and too easily. Even more, I'm into my Portland Knowledge Lab (PKL) business (gotta pay that rent today) and want to make lots of Python and Synergetics teaching cartoons for HDTV (my Saturday Morning meme), with lots of brand name sponsors. But here is not the place to brainstorm in safety. Too many prying eyes and self-appointed kibbitzers. So I'm actually resigning this time. Don't expect me back any time soon. Probably won't be tracking either, at least not with any frequency. For me, it's a tilt towards private lists and closed source development (not exclusively -- I'm still a big supporter of a strong public sector). I'm learning why open source is a bad idea sometimes. I've talked to Stallman about this, though he probably doesn't remember -- I was in his audience in Portland and asked about situations when "they" simply *don't deserve* your best code. But I think more it's a matter of not wanting to show unfinished work (a big no no in Fuller's self discipline, according to 'Critical Path' I think it was). Kirby

2 3

Pre-PEP was: The fate of raw_input() in Python 3000
by Andre Roberge Jan. 7, 2007

Jan. 7, 2007

Hi-all, Having had a look at the discussion on the Python-3000 mailing list, I thought it was appropriate to write a draft PEP with the intent of eventually posting it on the Python 3000 list for "serious" discussion/future decision. This proposal could most certainly be strengthened, and the wording improved by a native English speaker with stronger CS background than I have. I have attempted to follow the standard recommended format (including providing both a motivation and rationale ... which seemed a bit redundant and an artificial split...) Feel free to make comments for improvement and even take over the "ownership" of this PEP. André ========================================= PEP: XXX Title: Simple input built-in in Python 3000 Version: $Revision: 0.1 $ Last-Modified: $Date: 2006/09/13 20:00:00 $ Author: André Roberge <andre.roberge(a)gmail.com> Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 13-Sep-2006 Python-Version: 3.0 Post-History: Abstract ======== Input and output are core features of computer programs. Currently, Python provides a simple means of output through the print keyword and two simple means of input throught the input() and raw_input() built-in functions. Python 3.0 will introduces various incompatible changes with previous Python versions[1]. Among the proposed changes, print will become a built-in function, print(), while input() and raw_input() would be removed completely from the built-in namespace, requiring importing some module to provide even the most basic input capability. This PEP proposes that Python 3.0 retains some simple user input capability, equivalent to raw_input(), within the built-in namespace. Motivation ========== With its easy readability and its support for many programming styles (e.g. procedural, object-oriented, etc.) among others, Python is perhaps the best computer language to use in introductory programming classes. Simple programs most often need to contain a means to provide information to a user (output) as well as obtaining information from that user (input). Any computer language intended to be used in an educational setting should provide straightforward methods for both input and output. The current proposals for Python 3.0 [1] include a simple output pathway via a built-in function named print(), but a more complicated method for input [e.g. via sys.stdin.readline()], one that requires importing an external module. Current versions of Python (pre-3.0) include raw_input() as a built-in function. With the availability of such a function, programs that require simple input/output can be written from day one, without requiring discussions of importing modules, streams, etc. Rationale ========= Current built-in functions, like input() and raw_input(), are found to be extremely useful in traditional teaching settings. (For more details, see the discussion that followed [3].) While the BDFL has clearly stated [3] that input() was not to be kept in Python 3000, he has also stated that he was not against revising the decision of killing raw_input(). raw_input() provides a simple mean to ask a question and obtain information from a user. The proposed plans for Python 3.0 would require the replacement of the single statement speed = raw_input("What is the average airspeed velocity of an unladed swallow?") by the more complicated import sys print("What is the average airspeed velocity of an unladed swallow?") speed = sys.stdin.readline() The removal of raw_input (or equivalent) would not significantly reduce the built-in namespace while it would steepen significantly the learning curve for beginners. Specification ============= The built-in input function should be totally equivalent to the existing raw_input() function. Open issues =========== With input() effectively removed from the language, the name raw_input() makes much less sense and alternatives should be considered. The various possibilities mentioned in various forums include: ask() ask_user() get_string() input() # rejected by Guido prompt() read() user_input() References ========== .. [1] Miscellaneous Python 3.0 Plans (http://www.python.org/dev/peps/pep-3100/) ..[2] The fate of raw_input() in Python 3000 (http://mail.python.org/pipermail/edu-sig/2006-September/006967.html) .. [3] educational aspects of Python 3000 http://mail.python.org/pipermail/python-3000/2006-September/003589.html Copyright ========= This document has been placed in the public domain.

5 8

FYI: PataPata postmortem link
by Paul D. Fernhout Dec. 5, 2006

Dec. 5, 2006

Just as an FYI, as a way to wind up the PataPata project (or at least one phase of it), I wrote a lengthy postmortem critique of the PataPata project to date, plus ideas for where to go from here. You can read the critique by following this link: "PataPata critique: the good, the bad, the ugly" http://sourceforge.net/mailarchive/forum.php?thread_id=31111569&forum_id=48… Comments welcome. For reference, the PataPata project is/was """an experiment to support educational constructivism on the Python platform, inspired by "Squeak" and "Self", but going beyond those in a Pythonic way.""" From the introduction: """It's been about three months from my last post to the PataPata list as well as my last major change to the system. I have been thinking about the system in the intervening time, and feel ready to produce a critique of it as an experiment (sort of as a, sadly, "postmortem" report). Others are welcome to chime in. This critique covers various good, bad, and ugly results from this experiment, and then outlines some thoughts on where to go next. This note marks the end of this phase of the PataPata experiment. I am uncertain if this project on SourceForge will see more development, but I am certain if there is more development on this particular SourceForge project, it will likely be in a radically different direction than the work published here to date. """ === By the way, my decision to write a critique of PataPata was inspired in part by this paper by Drew McDermott, "Artificial Intelligence meets Natural Stupidity". http://portal.acm.org/citation.cfm?id=1045340 [fee based link] The core of the paper is here: http://www.everything2.com/index.pl?node_id=1406540 From there: "McDermott explains how all research should be based on actual implementations, and be a thorough report on them. What is needed is a very clear picture of what was tried, what worked, what didn't, why didn't that work. And there must be a working program that later researchers can play with. Later research can build on these partial solutions, and report the exact improvements made since the previous version, the improvement in performance, etc. As McDermott states: The standard for such research should be a partial success, but AI as a field is starving for a few carefully documented failures. Anyone can think of several theses that could be improved stylistically and substantively by being rephrased as reports on failures. I can learn more by just being told why a technique won't work than by being made to read between the lines." Thanks again to people here for your previous feedback on the project. --Paul Fernhout

9 26

Re: [Edu-sig] FYI: PataPata postmortem link
by David Boddie Dec. 1, 2006

Dec. 1, 2006

On Wed, 29 Nov 2006 10:29:30 -0600, Ian Bicking wrote: [Constrained objects and persistence] >In particular cases it might be more reasonable. For instance, consider >glade (http://glade.gnome.org/) -- it's an XML description of a GUI. >For an application that uses Glade and given an editor specific to that, >you could edit the "objects" and then the XML is automatically written >out. You'd be doing simultaneous editing of the in-process objects and >the "source code", in this case the XML description of the layout. Sure. The interesting things begin when you start to (ab)use these layout tools to describe processes. For example, using Qt Designer's signals and slots editor to describe higher-level actions in an application. >Glade isn't magic, of course -- you could add automatic serialization to >any kind of object, or recreate something like Glade in Python. For a >small number of basic Python objects this is already possible; mostly >functions. Modules and classes are not nearly so simple. Rather than serialising Python objects, it's possibly easier to think about describing components that can be implemented in Python. This means that you're no longer editing Python, but tweaking parameters for some set of components in a flowchart, and optionally rearranging them to do different things. Maybe that's a step too far. >But really if we can cover a set of compelling things that children >would want to edit, an incomplete in-process editing system could be >valuable. I agree. >Forking would clone a process. I'm not really interested in cloning the process. I'm thinking about restarting individual "smaller" processes - that is, processes with fewer responsibilities than normal applications. You would need more than one of these to do interesting things, and they would communicate through interfaces. [Reloading modules] >As a result there's lots of references to the old objects. For every >class there is now two instances of the class. Any imports like "from >mod import Foo" will still be pointing at the old Foo. There might be >references to functions, bound methods, etc, and old instances with a >__class__ pointing to the old definition. Sure. That's why it would be interesting to use clearly-separated components that can be reconfigured and (re)started. >People have implemented fancier reloaders that do better. For instance, >recursively replacing the __dict__ of classes, instead of just creating >a new class. There are always cases in which these fail. > >That said, if we could identify those cases and give warnings we'd be >getting a lot further. Current reloaders are optimistic and ignore >detectable problems. Once the warnings are in, and given alternate >methods (e.g., alternatives to mutable class-level variables), we would >be encouraging people to write reloadable code. Or maybe just turn everything into separated components; or use a different way to describe discrete packages of Python, perhaps inspired by an existing XML format for GUIs. There's lots of scope for different approaches, but it's quite easy to get distracted by the detailed techniques required to achieve them. As PataPata has perhaps taught us, I think it's important to establish some limits on what you want to achieve and remain focused on that. David

2 1

Re: [Edu-sig] OLPC (was FYI: PataPata postmortem link)
by David Boddie Nov. 30, 2006

Nov. 30, 2006

On Wed Nov 29 16:17:12 CET 2006, Bert Freudenberg bert wrote: > On Nov 29, 2006, at 16:06 , Tom Hoffman wrote: > > > > I would point out that writing educational software for people who > > don't have computers isn't very useful either, and that once kids have > > computers (on a common, free platform) there's a lot more incentive to > > write educational software for them. > > Exactly my reasoning - OLPC is going to be a common, free platform, > so it should be plenty of incentive. Yet, little is happening. There may be little _visible_ activity, but not everything is discussed and planned on edu-sig. ;-) Still, your concerns are valid. It may be that the OLPC program needs to reach out further to certain interested parties. David

1 0

Re: [Edu-sig] FYI: PataPata postmortem link
by David Boddie Nov. 29, 2006

Nov. 29, 2006

Ian Bicking wrote: > There's some similar issues being considered for OLPC. Specifically the > laptop has a "view source" key, which (unsurprisingly) lets you view the > source of what you are doing. What that means is application (aka > "Activity") specific, but a general Python solution is called for. > > Of course it's a little hard to say what that actually should be. Just > a text editor? Not too exciting. Really there should be a view of the > process. And some way to manipulate the in-process objects and source. When I hear something like this, I think of pipelines or trees of self-contained components rather than source-level objects. Wasn't there a talk at EuroPython 2006 about data processing that covered this approach? [...] > Of course, at some point you need complete power, which means editing > the source in ways that can only be meaningful when you restart the > process from scratch. I'm not sure how or where to make that break. > OTOH, emphasizing clean/fast/easy restarts might be more general and > easier to implement than in-process persistent editing. In many ways, it's more interesting to consider making modified copies of existing processes. It avoids difficult issues with in-process interaction and encourages something like a prototype-based approach. It seems to me that this might work well with simple components, but maybe I'm just trying to avoid facing those difficult issues. :-/ > I'm also not sure what to build on, or what to use. It's interesting > that you felt out-of-process interaction was successful. This fits with > my own intuition that in-process stuff can be dangerous and fragile. > But I'm not that familiar with the details of how the interprocess > communication should happen; perhaps IDLE is a good place to start > looking. Perhaps IDLE is a good place to start the development? My experiments have led me to believe that interaction between processes using their standard input, output and error streams is a fairly robust foundation on which to implement out-of-process editing facilities for use with simple editing environments. David

3 2

turtle-graphics - Abelson and a sign of the times?
by Gregor Lingl Nov. 19, 2006

Nov. 19, 2006

> Concerning books what I've done is to rely on the old, but very good > book, by Abelson and diSessa "Turtle Geometry" (MIT Press) and > translate the logo code to Python. To confront you with a newer (and very interesting) idea of Abelson have a look at: ttp://lambda-the-ultimate.org/node/1840 Regards, Gregor P.S.: After having finished the second edition of "Python für Kids" which was a huge rewrite due to using the new xturtle module I went on vacation. Back from this I've got to do a lot of work which I didn't have time to complete while writing the book. I just have turned on the edu-sig posting delevery again and I hope to be able to enter the turtlegraphics thread soon and also the development of the xturtle module in the very near future.

1 0

Re: [Edu-sig] experiences teaching Python with turtle graphics?
by Daniel Ajoy Nov. 19, 2006

Nov. 19, 2006

On 18 Nov 2006 at 12:00, edu-sig-request(a)python.org wrote: > As has been mentioned, looking at Logo resources is probably the best > thing to do. Wikipedia's entry on Logo is a reasonable place to start: > http://en.wikipedia.org/wiki/Logo_programming_language > I have a small collection of classic turtle graphics here: http://mondragon.angeltowns.net/paradiso/GaleriaGT.html And I've promoted this page in the past: http://mondragon.angeltowns.net/paradiso/Construcciones.html Daniel Del Paraiso de Logo (Logo Paradise)

1 0

experiences teaching Python with turtle graphics?
by Andy Judkis Nov. 17, 2006

Nov. 17, 2006

In a few weeks I am going to start the programming unit of my tenth grade computer applications course. This will be my 5th time through it, and the previous 4 times have been only partially satisfactory. The course I teach is required, and although the students are all fairly bright, they are not all enthusiastic about this kind of thing. We have about 4 weeks to spend on the programming portion. I've started with about 4 days of RUR-PLE, where students program a robot sprite to move around inside a maze. RUR-PLE is basically a Python version of Karl The Robot, with a nice interface and some very appealing graphics. This has worked out quite well as a starting point, and introduces some of the basic ideas of subroutines, branches, and loops in a constrained environment. I've found that students are quite surprised to see the kinds of complex behavior that can come from a few lines of code. My favorite student quote: "It's so logical, but so frustrating." >From there, they've gone on to using IDLE, writing the simple text-based "guess the number" sequence of programs that I've seen in several introductory books and the first chapter of the Livewires. This takes a few days, introducing variables and reiterating the looping and branching from RUR-PLE in a more free-form environment. Then we've gone on to do some ultra-simple graphics, using the Livewires primitives to draw circles, lines, etc. This reiterates the subroutines from RUR-PLE, and introduces (with mixed results) return values and parameters. Then we do a little bit with lists - I have them generate random Shakepearean insults from lists of words. >From there, they do some ultra-simple animation, using a loop with sleep() to move disks around and bounce them off the sides of the window, and polling the keyboard to use cursor keys to move objects around on the screen. At this point, about a quarter of the kids are really into it, and they make a simple pong-like game. The other three quarters are dying for the unit to be over. One poster here several weeks ago said that 70% of the kids in their programming courses never really "get it" and unfortunately that's been my experience as well. I'd really like to do better. I'm particularly interested in using Gregor Lingl's xturtle library. I know that versions of turtle graphics have been around for various environments for a long time but I've only started to look at it, and it seems like it should be a lot of fun. More specifically, it seems like if it is used wisely, it should appeal to more of the kids for a longer period of time, and still provide a platform for getting across the concepts. Does anybody out there have any specific experience with teaching Python to this kind of audience using turtle graphics? Are there any books or lesson plans available that you can recommend as a starting point? As a point of reference, the first time I tried to teach Python I thought that the Livewires course would be perfect but I quickly found that, as slow and gentle as it seems to an experienced programmer, it moves way too fast and has way too little hand-holding for most high school kids. Thanks, Andy Judkis Academy of Allied Health and Science Neptune, NJ

4 3

Re: [Edu-sig] Edu-sig Digest, Vol 40, Issue 9
by Toby Donaldson Nov. 17, 2006

Nov. 17, 2006

> I'd really like to do better. I'm particularly interested in using Gregor > Lingl's xturtle library. I know that versions of turtle graphics have been > around for various environments for a long time but I've only started to > look at it, and it seems like it should be a lot of fun. More specifically, > it seems like if it is used wisely, it should appeal to more of the kids for > a longer period of time, and still provide a platform for getting across the > concepts. > > Does anybody out there have any specific experience with teaching Python to > this kind of audience using turtle graphics? Are there any books or lesson > plans available that you can recommend as a starting point? As a point of > reference, the first time I tried to teach Python I thought that the > Livewires course would be perfect but I quickly found that, as slow and > gentle as it seems to an experienced programmer, it moves way too fast and > has way too little hand-holding for most high school kids. I've used turtle graphics briefly in short sessions with kids in grade 6/7, and they easily got it in just an hour or two. We walked through a simple set of tasks that lead to a an interesting final result. I think xturtle is very good; I've created a self-installing disutils package for Windows et al to distribute to my students. As has been mentioned, looking at Logo resources is probably the best thing to do. Wikipedia's entry on Logo is a reasonable place to start: http://en.wikipedia.org/wiki/Logo_programming_language My experience has been that most students enjoy turtle graphics, and there always some students who quickly bump into the limitations of the package. Even xturtle is not yet as flexible as a grade 6 student would like. :-) I think the Squeak approach is much more interesting, although its epic scope makes it difficult to do outside of Smalltalk. Toby -- Dr. Toby Donaldson School of Computing Science Simon Fraser University (Surrey)

1 0