From john.zelle at wartburg.edu Mon May 1 02:25:34 2006 From: john.zelle at wartburg.edu (John Zelle) Date: Sun, 30 Apr 2006 19:25:34 -0500 Subject: [Edu-sig] Don't kids program anymore? In-Reply-To: References: Message-ID: <200604301925.34971.john.zelle@wartburg.edu> This has been an interesting thread. I haven't had time to contribute, but I saw something here that I felt I had to address. On Sunday 30 April 2006 14:47, kirby urner wrote: > On 4/30/06, Michael Tobis wrote: > > Most kids, most humans in general, will voluntarily spend many hours > > in such environments. The game industry proves this. That the graphics > > are amusing is secondary to the design of interesting vs dull games. > > What keeps games interesting is that they stay near the optimum flow > > point between triviality and frustration. This impulse can and should > > be channelled toward useful skills. > > > > mt > > I'm glad you mention REWARD. Many of us share this vision: find a > way to disburse credits via distance education circuits such that > those putting in the hard work of actually learning this stuff > actually get rewarded, and not just in heaven, but on this very Earth > as well. You'd think it wouldn't be so hard, given ample precedents, > including clippable coupons or ID specific promotionals (e.g. use this > code for a free subscription to...). We need to be very careful about "rewards" in this context. A lot of psychological research suggests that once a person is "paid" for doing something that is fun to them, it ceases to be fun and they tend not to do it anymore unless they are paid. One of the real problems in our educational system is that we unwittingly train our students that everything should be done for external rewards (a good grade now, a better job later). Learning becomes something to be done for external reasons, rather than doing it for the joy of learning itself. That leads to all sorts of negative outcomes (rampant cheating is one). In a video game, the compelling reward is simply being good at the game. In learning to program, the reward should be the sense of accomplishment and empowerment that comes with mastering a bit of that craft. I fear that any other type of reward is counterproductive in the long run. > As soon as you start making a return (maybe not in terms of cash, but > in terms of barter, which eCommerce makes easier), the "school space" > gives way to the "work place" i.e. they're paying you instead of > you're paying them -- or at least it's more of a 2-way street. > > Relevant: > http://worldgame.blogspot.com/2006/04/computer-lab-as-playground.html > > Kirby > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig -- John M. Zelle, Ph.D. Wartburg College Professor of Computer Science Waverly, IA john.zelle at wartburg.edu (319) 352-8360 From kirby.urner at gmail.com Mon May 1 02:29:16 2006 From: kirby.urner at gmail.com (kirby urner) Date: Sun, 30 Apr 2006 17:29:16 -0700 Subject: [Edu-sig] Don't kids program anymore? In-Reply-To: <200604301925.34971.john.zelle@wartburg.edu> References: <200604301925.34971.john.zelle@wartburg.edu> Message-ID: > In a video game, the compelling reward is simply being good at the game. In > learning to program, the reward should be the sense of accomplishment and > empowerment that comes with mastering a bit of that craft. I fear that any > other type of reward is counterproductive in the long run. > Yes, this is a valid point, but in the context I'm thinking in, our students have very slim access to life support as it is, so the idea that a school might turn into a way for a village to receive income is too important to side-step. In fact, TuxLabs already tend to be used as businesses after hours. The same machines lead a double life: school teachers by day, work stations by night. Bascially, we're looking at the guild system, with an apprenticeship leading to gigs of one's own. When the new talent is judged ready for prime time is largely up to the guild, so I won't presume to dictate too much (except within mine I'll likely remain a source of feeback -- I need to pay attention to quality where my own bona fides are concerned). Kirby From kirby.urner at gmail.com Mon May 1 03:29:55 2006 From: kirby.urner at gmail.com (kirby urner) Date: Sun, 30 Apr 2006 18:29:55 -0700 Subject: [Edu-sig] CFC: An Atlas of Linguistic Graphs In-Reply-To: <20060430191548.byyizj7k7wkgokc4@webmail.polimetrica.com> References: <20060430191548.byyizj7k7wkgokc4@webmail.polimetrica.com> Message-ID: Have you done a survey of existing semantic web projects? http://en.wikipedia.org/wiki/Semantic_web http://www.w3.org/2001/sw/hcls/ Kirby From kirby.urner at gmail.com Mon May 1 06:28:28 2006 From: kirby.urner at gmail.com (kirby urner) Date: Sun, 30 Apr 2006 21:28:28 -0700 Subject: [Edu-sig] Don't kids program anymore? In-Reply-To: References: Message-ID: > Interesting indeed. In addition to John's interesting concern, there > is also the practical issue of how would you prevent someone from > solving the same problem over and over again, repeating the same work > for a different dollar? Well, it's worth something to get each kid literate, so the rewards begin. I'm not talking money necessarily. We give "credits" even today, e.g. a pass on to the next reading, more interesting challenges. The point is it doesn't matter if the same reading is mastered over and over, as each time, the reader is different. > That's not what I meant though. I meant that solving problems is > intrinsically rewarding. Look at Sudoku, about as visually dull a > prospect as imaginable, and yet providing a systematic set of > increasingly difficult problems. Many people spend considerable time > on it. It's not the decorations and the sound effects, it's the > problem solving and skill building itself that is what makes a game, > especially a solitaire game, attractive. People do like to learn. > > mt Yes, I agree these pleasant intellectual rewards exist. However, to be productive, students need better access to tools of the trade, and so, as they distinguish themselves, their credit towards various assets will increase. Study biology real hard, and it's more likely your village laboratory will get another microscope for you to use. Kirby From kirby.urner at gmail.com Mon May 1 06:33:38 2006 From: kirby.urner at gmail.com (kirby urner) Date: Sun, 30 Apr 2006 21:33:38 -0700 Subject: [Edu-sig] Simple Fractal Message-ID: Here's a simple Mandelbrot class I plan to use next week. The output is mindless in this case, but reminiscent of what Mandelbrot first started seeing at IBM i.e. vague X-ray visions, nothing like the high resolution colorful MRI photographs we get today. In this case, the output is just ascii characters. Future subclasses will take the same information and convert it to POV-Ray and/or VPython, with a color palette added (color is a function of the rate of divergence). Anyway, just studying this source code helps make the concept of "Mandelbrot Set" become clear, once you've mastered basic Python. >>> import quickfractal >>> f = quickfractal.Mandelbrot((-3,-2),(2,2),0.05) >>> f.checkc() """ quickfractal.py range through complex plane, lower left to upper right, generating corresponding ascii depending on whether z = z*z + c converges or diverges. """ class Mandelbrot (object): def __init__(self, lowleft, upright, step, filename="simpfract.txt", filepath="c:/python24/Lib/site-packages/"): self.lowleft = lowleft self.upright = upright self.step = float(step) self.filename = filename self.filepath = filepath def checkc(self): output = file(self.filepath + self.filename, 'w') re = self.lowleft[0] while re <= self.upright[0]: im = self.lowleft[1] while im <= self.upright[1]: c = complex(re,im) z = 0j for k in range(7): z = z**2 + c if abs(z)<10: output.write('*') # converges else: output.write('.') # diverges im += self.step re += self.step output.write('\n') output.close() From andre.roberge at gmail.com Mon May 1 14:20:10 2006 From: andre.roberge at gmail.com (Andre Roberge) Date: Mon, 1 May 2006 09:20:10 -0300 Subject: [Edu-sig] Learning Python via a browser: looking for a name Message-ID: <7528bcdd0605010520se2c3183iec79663ec6bbe1c9@mail.gmail.com> Imagine, if you will, that, through your browswer, you could interact with the Python tutorial, instead of simply reading it, and really try Python. For a concrete example, here's a modified snippet from the tutorial: #==== 3.1.1 Numbers The interpreter acts as a simple calculator: you can type an expression at it and it will write the value. Expression syntax is straightforward: the operators +, -, * and / work just like in most other languages (for example, Pascal or C); parentheses can be used for grouping. For example: >>> 2+2 4 BOX(>>>) #================ Where BOX(>>>) represents a one-line "box" (html form with text input) in which you could actually type "2+2", and see that you can reproduce the actual example. Ok, that shouldn't be too hard to imagine, as there are already a few apps that can be adapted to do this, the latest being Ian Bicking's HTConsole. Now, imagine if you could also embed some longer examples, no longer at the interpreter prompt, but as some small scripts, and let the user edit them. Then, at the press of a button, you could execute them, and repeat the edit-run cycle as often as you wished, all within your browser. [This is referred to as TEXTBOX() below.] Again, that shouldn't be too hard to do... Then, imagine that you could also have the option to include docTest quiz as described by Jeff Elkner at http://dc.ubuntu-us.org/projects/doctest-quiz.php and mentioned previously on this list. The way you could have this is to have a webpage that looks as follows: #========= Question 1: Write just enough Python code to make the following DocTests pass: """ >>> a = Animal() >>> a.name '' >>> a.friends [] """ TEXTBOX() #============= Running this would invoke invoke properly the docTest module, combining the sample docTest embedded in the page together with the user written code. Imagine if some such tutorials could be designed by anyone, by simply writing standard html documents, with just a few additional arguments, e.g.

""" >>> a = Animal() >>> a.name '' >>> a.friends [] """

Finally, imagine if you could have, side-by-side, a TEXTBOX and a area where you could try turtle graphics. All within your standard webbrowser. The good news is that I have working prototypes for all of the above *except* the last one - but I am pretty sure I know (in principle) how to do that one too. [I'm proud to say that I only use Python - not a single javascript line of code. ;-)] One small caveat: it runs entirely on a single computer - for security reasons. But, if there was a way to have a server-side sandbox, it could be adapted by (I think) changing just one line of code. Now, I'm working (very much part time) on this and would like to release a prototype for public usage within the next few weeks. However, I have no idea what to call it. I've thought of oblique references to Monty Python (e.g. LwB: Learn with Brian - referring to LoB), or made up acronyms (Web Interface to Learn Python, or WILP), but I haven't thought of anything inspiring. So, if you have some suggestions for a name, or if you want to be pre-alpha test user, feel free to contact me directly. Any additional suggestions about additional features for such a program should probably be directed to this list. Andr? From mtobis at gmail.com Mon May 1 16:13:56 2006 From: mtobis at gmail.com (Michael Tobis) Date: Mon, 1 May 2006 09:13:56 -0500 Subject: [Edu-sig] Learning Python via a browser: looking for a name In-Reply-To: <7528bcdd0605010520se2c3183iec79663ec6bbe1c9@mail.gmail.com> References: <7528bcdd0605010520se2c3183iec79663ec6bbe1c9@mail.gmail.com> Message-ID: We are thinking very much along the same lines in terms of the experience we intend to provide to the student. Your efforts are somewhat orthogonal to my preliminary goal of having secure doctests that are verified on the server but run on the client. I think we should coordinate so that our efforts can cooperate. I think these goals are not competing; the didactic doctests and the authentication doctests serve different purposes. A well-designed interactive tutorial environment is something we all want, and I encourage your efforts in this direction. The crucial issue, I think, in the success of such a project is ease of deployment. The student must have either an egg to hatch or a web page to visit. However, I am surprised to find myself inclined to the specialized client rather than the web solution. (The "rich client" or "iTunes" model) The server must either be 1) very easy to install (the skills at a typical school are shockingly low) or 2) low maintenance and highly scalable (so that skilled volunteer efforts would be sufficient. Either of these approaches becomes more difficult as the graphics load is moved to the server. A localhost solution is not going to be deployable at all, I'm afraid. We will never have the tech support resources to get webservers installed on every student's computer. I guess this means you do need to address the sandbox question, which in turn puts quite acomputational load on the server and a time and skills demand on the sysadmin. Then if you do server side greaphics rendering, you will have a hard time getting satsifactory performance, unless there is *serious* infrastructure funding. It also assumes that the student has reliable broadband. So for scalability, deployment, and support as well as security, I think computations should be done on the client, and the end user should not be required to run a localhost server. When I first started thinking along these lines I expected a browser and a webserver would be part of the design, but I now am inclined to doubt it. mt From kirby.urner at gmail.com Mon May 1 16:28:30 2006 From: kirby.urner at gmail.com (kirby urner) Date: Mon, 1 May 2006 07:28:30 -0700 Subject: [Edu-sig] Learning Python via a browser: looking for a name In-Reply-To: References: <7528bcdd0605010520se2c3183iec79663ec6bbe1c9@mail.gmail.com> Message-ID: > A localhost solution is not going to be deployable at all, I'm afraid. > We will never have the tech support resources to get webservers > installed on every student's computer. > I think you should revisit this assumption. Python is quite capable of firing up a local web server, written in Python, and directly on the client. This is how the module docs work in Windows right out of the box e.g. a Tk search returns a list of doc pages, and a selection fires up such as http://localhost:7464/CGIHTTPServer.html. Python users are also used to local hosting as a part of the installer if they've ever played around with Zope or Plone (but a tutoring server needn't be so complicated as medusa, an asynchronous server designed for multiple simultaneous users). Kirby From andre.roberge at gmail.com Mon May 1 17:35:44 2006 From: andre.roberge at gmail.com (Andre Roberge) Date: Mon, 1 May 2006 12:35:44 -0300 Subject: [Edu-sig] Learning Python via a browser: looking for a name In-Reply-To: References: <7528bcdd0605010520se2c3183iec79663ec6bbe1c9@mail.gmail.com> Message-ID: <7528bcdd0605010835i1c6e1964l5328295f04456dc1@mail.gmail.com> On 5/1/06, Michael Tobis wrote: > We are thinking very much along the same lines in terms of the > experience we intend to provide to the student. > ... [snip] > I think we should coordinate so that our efforts can cooperate. I > think these goals are not competing; the didactic doctests and the > authentication doctests serve different purposes. Agreed! What we really need, I think, is to think of what kind of pedagogical material needs to be developped, and how we would want to have the user interract with it. My approach, which I see as being just a prototype, should allow us to experiment with different models. > > A well-designed interactive tutorial environment is something we all > want, and I encourage your efforts in this direction. The crucial > issue, I think, in the success of such a project is ease of > deployment. The student must have either an egg to hatch or a web page > to visit. If the student has Python on his computer, my little app could be delivered as an egg or downloaded from a web page. > However, I am surprised to find myself inclined to the specialized > client rather than the web solution. (The "rich client" or "iTunes" > model) My current approach is that of a desktop app (i.e. the server and the client are running on the same computer). When I start the application, it starts the server and launches a browser window (or, in my case, if Firefox is running, opens up a new page in a separate tab). > > The server must either be 1) very easy to install (the skills at a > typical school are shockingly low) or 2) low maintenance and highly > scalable (so that skilled volunteer efforts would be sufficient. > Either of these approaches becomes more difficult as the graphics load > is moved to the server. My approach requires that the following be installed on the computer: 1. A browser 2. Python :-) 3. Elementtree (included in Python 2.5?) 4. CherryPy 5. My yet-unnamed app. It could bundle CherryPy so that it would be a single app to "install", if Python is already present. > A localhost solution is not going to be deployable at all, I'm afraid. > We will never have the tech support resources to get webservers > installed on every student's computer. I see that Kirby addressed this point in his reply. > > I guess this means you do need to address the sandbox question, which > in turn puts quite acomputational load on the server and a time and > skills demand on the sysadmin. Then if you do server side greaphics > rendering, you will have a hard time getting satsifactory performance, > unless there is *serious* infrastructure funding. It also assumes that > the student has reliable broadband. The sandbox question should be adressed if it is to be run from an external server. As for the performance, for non-graphical stuff, it should be fairly fast as is. Using things like AJAX (which I know very little about - just to throw an acronym at you ;-), when can exchange a minimum amount of information, reducing the need for broadband. For graphical stuff ... I did a small experiment where I launched a pygame window from the code entered by the user [me :-)] in the browser window. It was just a proof of concept thing that I need to work on to make it better. > > So for scalability, deployment, and support as well as security, I > think computations should be done on the client, and the end user > should not be required to run a localhost server. Doing (Python) computation on the client is what I already do; the localhost server is just a small addition (if doing intensive graphics stuff). Andr? From mtobis at gmail.com Mon May 1 18:12:49 2006 From: mtobis at gmail.com (Michael Tobis) Date: Mon, 1 May 2006 11:12:49 -0500 Subject: [Edu-sig] Learning Python via a browser: looking for a name In-Reply-To: <7528bcdd0605010835i1c6e1964l5328295f04456dc1@mail.gmail.com> References: <7528bcdd0605010520se2c3183iec79663ec6bbe1c9@mail.gmail.com> <7528bcdd0605010835i1c6e1964l5328295f04456dc1@mail.gmail.com> Message-ID: On 5/1/06, Andre Roberge wrote: > > So for scalability, deployment, and support as well as security, I > > think computations should be done on the client, and the end user > > should not be required to run a localhost server. > > Doing (Python) computation on the client is what I already do; the > localhost server is just a small addition (if doing intensive graphics stuff). OK, fair enough. Thanks both. Perhaps I was just not thinking clearly before my first cup of coffee took effect. I am imagining, ultimately, a very ambitious project relying on network effects in the social sense. In connecting to the internet in that context I still think the architecture must be that the student's machine is an HTTP client, because anything else would raise a lot of complexity. However, whether the browser and a custom localhost is involved is a design decision that is independent of all that, and it is indeed quite a reasonable approach. I was wrong in suggesting otherwise in my previous comment. I was imagining Apache and CGI and an RDBMS and so on, but as Kirby points out this is completely unnecessary. mt From ianb at colorstudy.com Mon May 1 18:19:19 2006 From: ianb at colorstudy.com (Ian Bicking) Date: Mon, 01 May 2006 11:19:19 -0500 Subject: [Edu-sig] Learning Python via a browser: looking for a name In-Reply-To: <7528bcdd0605010520se2c3183iec79663ec6bbe1c9@mail.gmail.com> References: <7528bcdd0605010520se2c3183iec79663ec6bbe1c9@mail.gmail.com> Message-ID: <44563507.3060108@colorstudy.com> Andre Roberge wrote: > Imagine, if you will, that, through your browswer, you could interact > with the Python tutorial, instead of simply reading it, and really try > Python. For a concrete example, here's a modified snippet from the > tutorial: > #==== > 3.1.1 Numbers > > The interpreter acts as a simple calculator: you can type an > expression at it and it will write the value. Expression syntax is > straightforward: the operators +, -, * and / work just like in most > other languages (for example, Pascal or C); parentheses can be used > for grouping. For example: > > >>>>2+2 > > 4 > BOX(>>>) > #================ > Where BOX(>>>) represents a one-line "box" (html form with text input) > in which you could actually type "2+2", and see that you can reproduce > the actual example. You might want to look at how trypy (http://trac.pocoo.org/browser/trypy) presents the material, which is in turn based on Try Ruby (http://tryruby.hobix.com/) I actually think the doctest approach is nicer and less linear. > Ok, that shouldn't be too hard to imagine, as there are already a few > apps that can be adapted to do this, the latest being Ian Bicking's > HTConsole. > > Now, imagine if you could also embed some longer examples, no longer > at the interpreter prompt, but as some small scripts, and let the user > edit them. Then, at the press of a button, you could execute them, > and repeat the edit-run cycle as often as you wished, all within your > browser. [This is referred to as TEXTBOX() below.] Note in HTConsole you can embed larger examples as functions; e.g., "from tutorial import *" will bring in all the functions into the current environment, in an editable form. Or load(), which would probably be cleaner in practice. > Again, that shouldn't be too hard to do... > > Then, imagine that you could also have the option to include docTest > quiz as described by Jeff Elkner at > http://dc.ubuntu-us.org/projects/doctest-quiz.php > and mentioned previously on this list. The way you could have this is > to have a webpage that looks as follows: > #========= > Question 1: Write just enough Python code to make the following DocTests pass: > > """ > >>> a = Animal() > >>> a.name > '' > >>> a.friends > [] > """ > TEXTBOX() > #============= > Running this would invoke invoke properly the docTest module, > combining the sample docTest embedded in the page together with the > user written code. > > Imagine if some such tutorials could be designed by anyone, by simply > writing standard html documents, with just a few additional arguments, > e.g. >

> """ > >>> a = Animal() > >>> a.name > '' > >>> a.friends > [] > """ >

Incidentally, I've been planning soon to write a doctest HTML parser. It shouldn't be too hard, I think; doctest is mostly already factored for this. I'll write it as a separate library. The one nuisance is that line numbers don't mean much in HTML, but they are embedded into doctest. I'm guessing I'll have a routine to "convert" a doctest HTML file, from: 
    >>> foo(
    ...  bar)
    baz
to: 
   >>> foo(
   ...  bar)
   baz
Or... I don't know what. Heck, as long as I'm doing all that, maybe I'll just make the report a modified version of the original test. Prettier anyway. > Finally, imagine if you could have, side-by-side, a TEXTBOX and a > area where you could try turtle graphics. All within your > standard webbrowser. Alan Kay's Logo has embedded turtle graphics: http://www.logowiki.net/ -- something perhaps to steal. (I've tried successfully with Firefox 1.5, but in 1.0.7 it isn't working) Doctesting graphics is hard :-/ -- if the graphics were more constrained, it actually wouldn't be so hard. Karel for instance is within the scope of doctestability. Would require some fancy doctest hacking, but at least possible. > The good news is that I have working prototypes for all of the above > *except* the last one - but I am pretty sure I know (in principle) how > to do that one too. [I'm proud to say that I only use Python - not a > single javascript line of code. ;-)] Boo! Javascript rocks! ;) > One small caveat: it runs entirely on a single computer - for security > reasons. But, if there was a way to have a server-side sandbox, it > could be adapted by (I think) changing just one line of code. One thing I'm planning on adding to HTConsole is to allow a user to give a password when starting it up (or, accessible from 127.0.0.1), and then after that a user with access can get a URL that will implicitly give access (one of those things like http://foo.com/access?longsignedstring). This way multiple users can access the same environment; HTConsole 0.2 makes that work a bit better (changes won't get pushed immediately, but if you hit you should see the other user's changes) Also IP based restrictions (beyond just 127.0.0.1), which are useful in computer labs. -- Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org From kirby.urner at gmail.com Mon May 1 18:33:46 2006 From: kirby.urner at gmail.com (kirby urner) Date: Mon, 1 May 2006 09:33:46 -0700 Subject: [Edu-sig] Learning Python via a browser: looking for a name In-Reply-To: References: <7528bcdd0605010520se2c3183iec79663ec6bbe1c9@mail.gmail.com> <7528bcdd0605010835i1c6e1964l5328295f04456dc1@mail.gmail.com> Message-ID: On 5/1/06, Michael Tobis wrote: > I am imagining, ultimately, a very ambitious project relying on > network effects in the social sense. In connecting to the internet in > that context I still think the architecture must be that the student's > machine is an HTTP client, because anything else would raise a lot of > complexity. Starting to sound a lot like Croquet, which is peer to peer. Dunno based on what protocol. I'm thinking maybe two generic categories of product, that needn't be confused: (1) A simpler interactive "in a browser" tutorial, that adds Python shell and interactive graphics to Mozilla or whatever. Like what Mr. Roberge is doing and related to early doctest experiments. (2) The more complex interactive "shared world" space, also with Python bindings, but with a back end that's more like a full-featured gaming engine with perhaps a custom non-browser client. More like the PySqueak vision. Kirby From andre.roberge at gmail.com Mon May 1 21:21:46 2006 From: andre.roberge at gmail.com (Andre Roberge) Date: Mon, 1 May 2006 16:21:46 -0300 Subject: [Edu-sig] Learning Python via a browser: looking for a name In-Reply-To: References: <7528bcdd0605010520se2c3183iec79663ec6bbe1c9@mail.gmail.com> <7528bcdd0605010835i1c6e1964l5328295f04456dc1@mail.gmail.com> Message-ID: <7528bcdd0605011221w6c6ef414i70cc7c23b6fe3abc@mail.gmail.com> On 5/1/06, kirby urner wrote: > On 5/1/06, Michael Tobis wrote: > > > I am imagining, ultimately, a very ambitious project relying on > > network effects in the social sense. In connecting to the internet in > > that context I still think the architecture must be that the student's > > machine is an HTTP client, because anything else would raise a lot of > > complexity. > > Starting to sound a lot like Croquet, which is peer to peer. Dunno > based on what protocol. > > I'm thinking maybe two generic categories of product, that needn't be confused: > > (1) A simpler interactive "in a browser" tutorial, that adds Python > shell and interactive graphics to Mozilla or whatever. Like what Mr. > Roberge is doing and related to early doctest experiments. > Mr. Roberge.... *MR.* Roberge .... Please, refer to me as Andr? or Andre (without the acute accent on the e if you must). If you have to be formal, then it's Dr. Roberge! :-) > (2) The more complex interactive "shared world" space, also with > Python bindings, but with a back end that's more like a full-featured > gaming engine with perhaps a custom non-browser client. More like the > PySqueak vision. > I totally agree about the distinction. Furthermore, I might add a different way to break it down in two categories: Learning to program, vs Programming to learn. What I am working on belongs mostly in the first category. Your (Kirby's) approach belongs mostly in the second (learning mathematics, through programming). Then, just to "contradict myself" (since Art is no longer around to make statements like that), I would probably have to say that (Py)Squeak is an environment designed to learn programming concept ... and learn about mathematics too. > Kirby > Andr? From delza at livingcode.org Mon May 1 22:27:30 2006 From: delza at livingcode.org (Dethe Elza) Date: Mon, 1 May 2006 13:27:30 -0700 Subject: [Edu-sig] Learning Python via a browser: looking for a name In-Reply-To: <7528bcdd0605011221w6c6ef414i70cc7c23b6fe3abc@mail.gmail.com> References: <7528bcdd0605010520se2c3183iec79663ec6bbe1c9@mail.gmail.com> <7528bcdd0605010835i1c6e1964l5328295f04456dc1@mail.gmail.com> <7528bcdd0605011221w6c6ef414i70cc7c23b6fe3abc@mail.gmail.com> Message-ID: <24d517dd0605011327l417dd670i594849f7596b80a0@mail.gmail.com> On 5/1/06, Andre Roberge wrote: > On 5/1/06, kirby urner wrote: > > On 5/1/06, Michael Tobis wrote: [snip] > Then, just to "contradict myself" (since Art is no longer around to make > statements like that), I would probably have to say that (Py)Squeak is > an environment designed to learn programming concept ... and > learn about mathematics too. re: (Py)Squeak I prefer Pipsqueak as a name %-) --Dethe > > > Kirby > > > Andr? > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > From andre.roberge at gmail.com Mon May 1 23:16:33 2006 From: andre.roberge at gmail.com (Andre Roberge) Date: Mon, 1 May 2006 18:16:33 -0300 Subject: [Edu-sig] Learning Python via a browser: looking for a name In-Reply-To: <24d517dd0605011327l417dd670i594849f7596b80a0@mail.gmail.com> References: <7528bcdd0605010520se2c3183iec79663ec6bbe1c9@mail.gmail.com> <7528bcdd0605010835i1c6e1964l5328295f04456dc1@mail.gmail.com> <7528bcdd0605011221w6c6ef414i70cc7c23b6fe3abc@mail.gmail.com> <24d517dd0605011327l417dd670i594849f7596b80a0@mail.gmail.com> Message-ID: <7528bcdd0605011416x5e5458f0ue80e870b39bed730@mail.gmail.com> On 5/1/06, Dethe Elza wrote: > On 5/1/06, Andre Roberge wrote: > > Then, just to "contradict myself" (since Art is no longer around to make > > statements like that), I would probably have to say that (Py)Squeak is > > an environment designed to learn programming concept ... and > > learn about mathematics too. > > re: (Py)Squeak > > I prefer Pipsqueak as a name %-) :-D That is to say ... as long you're not suggested this as a name for my app! (After all, my original rather long post included one and only one question: what should I name my app ;-) > --Dethe > Andr? From delza at livingcode.org Tue May 2 01:08:18 2006 From: delza at livingcode.org (Dethe Elza) Date: Mon, 1 May 2006 16:08:18 -0700 Subject: [Edu-sig] Learning Python via a browser: looking for a name In-Reply-To: <7528bcdd0605011416x5e5458f0ue80e870b39bed730@mail.gmail.com> References: <7528bcdd0605010520se2c3183iec79663ec6bbe1c9@mail.gmail.com> <7528bcdd0605010835i1c6e1964l5328295f04456dc1@mail.gmail.com> <7528bcdd0605011221w6c6ef414i70cc7c23b6fe3abc@mail.gmail.com> <24d517dd0605011327l417dd670i594849f7596b80a0@mail.gmail.com> <7528bcdd0605011416x5e5458f0ue80e870b39bed730@mail.gmail.com> Message-ID: <24d517dd0605011608m279fb90dq887d741380ef2bd3@mail.gmail.com> On 5/1/06, Andre Roberge wrote: > On 5/1/06, Dethe Elza wrote: > > On 5/1/06, Andre Roberge wrote: > > > Then, just to "contradict myself" (since Art is no longer around to make > > > statements like that), I would probably have to say that (Py)Squeak is > > > an environment designed to learn programming concept ... and > > > learn about mathematics too. > > > > re: (Py)Squeak > > > > I prefer Pipsqueak as a name %-) > > :-D > > That is to say ... as long you're not suggested this as a name for my > app! (After all, my original rather long post included one and only > one question: what should I name my app ;-) Which is funny, because I *had* forgotten the origin of the thread (and reading it in gmail it's easy to lose track--I don't see the thread title when I'm reading/replying). But no, I would call your app "All your web are belong to Python" or AYWABTP. It really flows off the tongue. Or maybe "Python in a Box." Or "A Taste of Python" (tastes like chicken) Something about spiders (the web) and snakes. Hmm., getting creepy. Which has "py" in it: "Cree.py" "Python Webs" Or, if you want to go with Monty Python, "Crunchy Frog" for no reason except it's a skit I can remember which I don't think has been used for a python package yet. --Dethe > > --Dethe > > > Andr? > From andre.roberge at gmail.com Tue May 2 01:24:30 2006 From: andre.roberge at gmail.com (Andre Roberge) Date: Mon, 1 May 2006 20:24:30 -0300 Subject: [Edu-sig] Learning Python via a browser: looking for a name In-Reply-To: <24d517dd0605011608m279fb90dq887d741380ef2bd3@mail.gmail.com> References: <7528bcdd0605010520se2c3183iec79663ec6bbe1c9@mail.gmail.com> <7528bcdd0605010835i1c6e1964l5328295f04456dc1@mail.gmail.com> <7528bcdd0605011221w6c6ef414i70cc7c23b6fe3abc@mail.gmail.com> <24d517dd0605011327l417dd670i594849f7596b80a0@mail.gmail.com> <7528bcdd0605011416x5e5458f0ue80e870b39bed730@mail.gmail.com> <24d517dd0605011608m279fb90dq887d741380ef2bd3@mail.gmail.com> Message-ID: <7528bcdd0605011624i55ae300dqfbd58298e90be4c7@mail.gmail.com> On 5/1/06, Dethe Elza wrote: > On 5/1/06, Andre Roberge wrote: > > On 5/1/06, Dethe Elza wrote: > > > On 5/1/06, Andre Roberge wrote: > > > > Then, just to "contradict myself" (since Art is no longer around to make > > > > statements like that), I would probably have to say that (Py)Squeak is > > > > an environment designed to learn programming concept ... and > > > > learn about mathematics too. > > > > > > re: (Py)Squeak > > > > > > I prefer Pipsqueak as a name %-) > > > > :-D > > > > That is to say ... as long you're not suggested this as a name for my > > app! (After all, my original rather long post included one and only > > one question: what should I name my app ;-) > > Which is funny, because I *had* forgotten the origin of the thread > (and reading it in gmail it's easy to lose track--I don't see the > thread title when I'm reading/replying). > > But no, I would call your app "All your web are belong to Python" or > AYWABTP. It really flows off the tongue. > Gotta love TLA [1] and EFLA [2] and their cousins. > Or maybe "Python in a Box." Cute... but I'm looking for something that could be use as a module name. > Or "A Taste of Python" (tastes like chicken) > > Something about spiders (the web) and snakes. Hmm., getting creepy. > Which has "py" in it: "Cree.py" Weirdly interesting. JaSON -like (Apologies to people that have never heard of Friday the 13th movies ... I've never seen them, but I can make this reference, which shows how pervasive popular culture is here...) > "Python Webs" > > Or, if you want to go with Monty Python, "Crunchy Frog" for no reason > except it's a skit I can remember which I don't think has been used > for a python package yet. > Hmmm since French is my mother tongue, I don`t know what to make of the Crunchy Frog suggestion ;-) Perhaps Guido, our Brother Dedicated to Foster Laughter through his inspirational use of Monty Python references, is still hanging around and will come up with a suggestion of his own. After all, I'd like to use his official tutorial as a sample application of this approach. I realise this is starting to stray quite a bit: I apologize to this hijacking of a list discussing educational application of python for the purpose of coming up with a name for my app. Follow-up privately by email are welcome. > --Dethe > Andr? [1] Three Letter Acronyms [2] Even Four Letter Acronyms From ianb at colorstudy.com Tue May 2 05:45:25 2006 From: ianb at colorstudy.com (Ian Bicking) Date: Mon, 01 May 2006 22:45:25 -0500 Subject: [Edu-sig] Google SoC mentors? Message-ID: <4456D5D5.109@colorstudy.com> Are there other people here signed up to mentor for the Google Summer of Code? Last year PSF rejected a couple good education proposals for lack of an appropriate mentor. Already one of the proposals is for an IDE similar to what Andre has described (GUI not web). (If anyone is curious about it, I can email you the proposal off list.) -- Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org From delza at livingcode.org Tue May 2 05:52:11 2006 From: delza at livingcode.org (Dethe Elza) Date: Mon, 1 May 2006 20:52:11 -0700 Subject: [Edu-sig] Learning Python via a browser: looking for a name In-Reply-To: <7528bcdd0605011624i55ae300dqfbd58298e90be4c7@mail.gmail.com> References: <7528bcdd0605010520se2c3183iec79663ec6bbe1c9@mail.gmail.com> <7528bcdd0605010835i1c6e1964l5328295f04456dc1@mail.gmail.com> <7528bcdd0605011221w6c6ef414i70cc7c23b6fe3abc@mail.gmail.com> <24d517dd0605011327l417dd670i594849f7596b80a0@mail.gmail.com> <7528bcdd0605011416x5e5458f0ue80e870b39bed730@mail.gmail.com> <24d517dd0605011608m279fb90dq887d741380ef2bd3@mail.gmail.com> <7528bcdd0605011624i55ae300dqfbd58298e90be4c7@mail.gmail.com> Message-ID: <24d517dd0605012052o591b1081g6e57ae65a9b055b6@mail.gmail.com> On 5/1/06, Andre Roberge wrote: > > Or, if you want to go with Monty Python, "Crunchy Frog" for no reason > > except it's a skit I can remember which I don't think has been used > > for a python package yet. > > Hmmm since French is my mother tongue, I don`t know what to make of > the Crunchy Frog suggestion ;-) OK, just one more post to clarify this issue, then I'll drop the thread too. Milton: We use only the finest baby frogs, dew picked and flown from Iraq, cleansed in finest quality spring water, lightly killed, and then sealed in a succulent Swiss quintuple smooth treble cream milk chocolate envelope and lovingly frosted with glucose. Praline: That's as maybe, it's still a frog. Milton: What else? Praline: Well don't you even take the bones out? Milton: If we took the bones out it wouldn't be crunchy would it? http://orangecow.org/pythonet/sketches/crunchy.htm I'm sure it's an important metaphor for something, but I can't for the life of my think of what. --Dethe From lac at strakt.com Tue May 2 08:47:56 2006 From: lac at strakt.com (Laura Creighton) Date: Tue, 02 May 2006 08:47:56 +0200 Subject: [Edu-sig] Learning Python via a browser: looking for a name In-Reply-To: Message from "kirby urner" of "Mon, 01 May 2006 09:33:46 PDT." References: <7528bcdd0605010520se2c3183iec79663ec6bbe1c9@mail.gmail.com> <7528bcdd0605010835i1c6e1964l5328295f04456dc1@mail.gmail.com> Message-ID: <200605020647.k426lusc012677@theraft.strakt.com> In a message of Mon, 01 May 2006 09:33:46 PDT, "kirby urner" writes: >Starting to sound a lot like Croquet, which is peer to peer. Dunno >based on what protocol. TeaTime (written by David Reed). Laura From aharrin at luc.edu Tue May 2 10:51:29 2006 From: aharrin at luc.edu (Andrew Harrington) Date: Tue, 02 May 2006 03:51:29 -0500 Subject: [Edu-sig] HTConsole In-Reply-To: <445038F9.5080303@colorstudy.com> References: <44501D3C.50307@colorstudy.com> <7528bcdd0604261909x7451053ex1e10f7513861a12a@mail.gmail.com> <44502AF8.2070807@colorstudy.com> <7528bcdd0604261936w4a6c7ab0m7e929dac4ce04608@mail.gmail.com> <445038F9.5080303@colorstudy.com> Message-ID: <44571D91.8070706@luc.edu> Dear Ian, I installed easy_install successfully and then I have this session, ending in an error: C:\Python24>easy_install htconsole Searching for htconsole Best match: htconsole 0.2 Processing htconsole-0.2-py2.4.egg htconsole 0.2 is already the active version in easy-install.pth Installing htconsole-script.py script to C:\Python24\Scripts Installing htconsole.exe script to C:\Python24\Scripts Using c:\python24\lib\site-packages\htconsole-0.2-py2.4.egg Processing dependencies for htconsole Searching for Cheetah>=2a Best match: Cheetah 2.0rc6 Downloading http://69.9.164.2/sourceforge/cheetahtemplate/Cheetah-2.0rc6.tar.gz error: Download error: (10061, 'Connection refused') Andy Harrington Ian Bicking wrote: >Andre Roberge wrote: > > >>Good news: this installed it properly. >> >>Bad news: it does not work here. It starts Firefox (my default browser) at the >>http://localhost:8001/ >>page, which then displays a server error. I've appended below the >>entire error message from the console. Unfortunately, I must quit for >>the night. >> >> > >I really should have tested that install. In this case it needed >Cheetah 2.0, but you got 1.0. I updated those and added some more links >and tested it out, so now just "easy_install htconsole" really should >work (as of version 0.1.1). > >Well, unless you don't have a recent version of setuptools. For people >who don't have that, grab this file: > > http://peak.telecommunity.com/dist/ez_setup.py > >Run that, which will install the newest version of easy_install, run >"easy_install htconsole" and you should be good to go. > > > > -- Andrew N. Harrington Computer Science Department Undergraduate Program Director Loyola University Chicago http://www.cs.luc.edu/~anh 512B Lewis Towers (office) Office Phone: 312-915-7982 Snail mail to Lewis Towers 416 Dept. Fax: 312-915-7998 820 North Michigan Avenue aharrin at luc.edu Chicago, Illinois 60611 From ianb at colorstudy.com Tue May 2 17:23:56 2006 From: ianb at colorstudy.com (Ian Bicking) Date: Tue, 02 May 2006 10:23:56 -0500 Subject: [Edu-sig] HTConsole In-Reply-To: <44571D91.8070706@luc.edu> References: <44501D3C.50307@colorstudy.com> <7528bcdd0604261909x7451053ex1e10f7513861a12a@mail.gmail.com> <44502AF8.2070807@colorstudy.com> <7528bcdd0604261936w4a6c7ab0m7e929dac4ce04608@mail.gmail.com> <445038F9.5080303@colorstudy.com> <44571D91.8070706@luc.edu> Message-ID: <4457798C.4010809@colorstudy.com> Andrew Harrington wrote: > Dear Ian, > I installed easy_install successfully and then I have this session, > ending in an error: > > C:\Python24>easy_install htconsole > Searching for htconsole > Best match: htconsole 0.2 > Processing htconsole-0.2-py2.4.egg > htconsole 0.2 is already the active version in easy-install.pth > Installing htconsole-script.py script to C:\Python24\Scripts > Installing htconsole.exe script to C:\Python24\Scripts > > Using c:\python24\lib\site-packages\htconsole-0.2-py2.4.egg > Processing dependencies for htconsole > Searching for Cheetah>=2a > Best match: Cheetah 2.0rc6 > Downloading > http://69.9.164.2/sourceforge/cheetahtemplate/Cheetah-2.0rc6.tar.gz > error: Download error: (10061, 'Connection refused') I've gotten this from time to time as well. Something with how easy_install downloads from SF -- I think it retries when it gets some kinds of failures, but not all, and SF mirrors fail a lot. If you try it once or twice more it'll probably work, or you can download http://sourceforge.net/project/showfiles.php?group_id=28961&package_id=20864&release_id=391008 And then run "easy_install FileYouJustDownloaded.tar.gz" -- Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org From winstonw at stratolab.com Tue May 2 21:19:15 2006 From: winstonw at stratolab.com (Winston Wolff) Date: Tue, 2 May 2006 15:19:15 -0400 Subject: [Edu-sig] Google SoC mentors? In-Reply-To: <4456D5D5.109@colorstudy.com> References: <4456D5D5.109@colorstudy.com> Message-ID: <1F54B80D-AA3F-4A22-9505-F809F7A68CDA@stratolab.com> I'm interested. Would you send me that IDE description? -ww On May 1, 2006, at 11:45 PM, Ian Bicking wrote: > Are there other people here signed up to mentor for the Google > Summer of > Code? Last year PSF rejected a couple good education proposals for > lack > of an appropriate mentor. Already one of the proposals is for an IDE > similar to what Andre has described (GUI not web). (If anyone is > curious about it, I can email you the proposal off list.) > > -- > Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig ______________________________________________________ winston wolff - (646) 827-2242 - http://www.stratolab.com learning by creating - video game courses for kids in new york From francois.schnell at gmail.com Tue May 2 22:17:25 2006 From: francois.schnell at gmail.com (francois schnell) Date: Tue, 2 May 2006 22:17:25 +0200 Subject: [Edu-sig] Mindstorm NXT and Python ? Message-ID: <13a83ca10605021317i2672a87fi2802a8988205397e@mail.gmail.com> Hello, I've just read the open source move of Lego concerning it's new Mindstorm NXT: http://slashdot.org/articles/06/05/02/111245.shtml http://mindstorms.lego.com/press/2057/Open%20Source%20Announcement.aspx The firmware sources and blue tooth protocols will be available. :) This definitely interest me and I'll buy one as soon as available (in August). I didn't find anything about using Minstorms with Python yet but it looks like there'a a SDK for Microsoft Visual Studio Express with VB, C#, J#, C++: http://msdn.microsoft.com/coding4fun/lego/default.aspx Even if Iron Python is not integrated in Visual Studio (I believe), using the classes with IronPython shouldn't be a problem (I imagine). Anyway I'm not a fan of .Net/Mono and I'll probably try to explore other ways . I want to see what can be done with Python and this Mindstorms NXT in particular in an "educational/constructivist" context. If you know any projects already using Python and the actual Mindstorms I'm also interested or your thoughts on the subject. Thanks francois -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20060502/91bc4cbd/attachment.htm From wescpy at gmail.com Wed May 3 17:07:45 2006 From: wescpy at gmail.com (w chun) Date: Wed, 3 May 2006 08:07:45 -0700 Subject: [Edu-sig] ANN: 2006 Python training May/Aug/Nov, San Francisco Message-ID: <78b3a9580605030807u7c9ad20cu5c6d0af80414cdeb@mail.gmail.com> *** 50% DISCOUNT to STUDENTS/TEACHERS *** Dear fellow list members, Below is the announcement we've just made this morning about our upcoming advanced Python course, May 17-19, 2006. This advanced course will be offered again in Nov 2006. In Aug 2006, we will have another intensive introduction to Python course. Please forward this msg to anyone whom you think would be interested or would benefit from Python training courses. This includes Plone, Zope, and Mailman groups as well. http://mail.python.org/pipermail/python-list/2006-May/339577.html We apologize in advance if you feel this is a commercial and off-topic message. We limit such correspondence to once every few months. Trying to help Python take over the world.... -Wesley - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - "Core Python Programming", Prentice Hall, (c)2007,2001 http://corepython.com wesley.j.chun :: wescpy-at-gmail.com python training and technical consulting cyberweb.consulting : silicon valley, ca http://cyberwebconsulting.com From andre.roberge at gmail.com Thu May 4 05:57:13 2006 From: andre.roberge at gmail.com (Andre Roberge) Date: Thu, 4 May 2006 00:57:13 -0300 Subject: [Edu-sig] [Ann] DocTest solution: Crunchy Frog Message-ID: <7528bcdd0605032057v2c59df43s886457ba3a483163@mail.gmail.com> Version 0.1 of Crunchy Frog has been released. It can be found at https://sourceforge.net/project/showfiles.php?group_id=125834 Crunchy Frog allows to transform a "traditional" Python tutorial into an interactive session within your favourite web browser. Three "modes" of interaction are currently possible: 1. one-liner, similar to the typical instruction at the Python interpreter. 2. multi-line Python code, as entered in a traditional editor, and executed by Python. 3. Solutions to doctests, as described by Jeff Elkner in a previous post. Crunchy Frog is more of a proof-of-concept than a serious application at this point. The code is rather messy, showing my total lack of experience with this type of program (web app). To use it you will also need to have installed Elementtree (included with Python 2.5?) and CherryPy. You do not need to install Crunchy Frog. To try it: read the 5 (short) pages long "tutorial" included, using your favourite browser. Then, start Crunchy Frog, and go through the tutorial again. The whole thing should be doable in less than 10 minutes. Andr? From kirby.urner at gmail.com Thu May 4 07:06:13 2006 From: kirby.urner at gmail.com (kirby urner) Date: Wed, 3 May 2006 22:06:13 -0700 Subject: [Edu-sig] [Ann] DocTest solution: Crunchy Frog In-Reply-To: <7528bcdd0605032057v2c59df43s886457ba3a483163@mail.gmail.com> References: <7528bcdd0605032057v2c59df43s886457ba3a483163@mail.gmail.com> Message-ID: On 5/3/06, Andre Roberge wrote: > Version 0.1 of Crunchy Frog has been released. It can be found at > https://sourceforge.net/project/showfiles.php?group_id=125834 > Hi Andr? -- Took a few more minutes than 10, but not many more. Got it working on Windows XP. I didn't figure out how to do the doctest example properly, but that's probably because I'm rusty on that score. SnakeSkin? Kirby From pdfernhout at kurtz-fernhout.com Thu May 4 14:37:26 2006 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Thu, 04 May 2006 08:37:26 -0400 Subject: [Edu-sig] PySqueak issues: image storage Message-ID: <4459F586.1090803@kurtz-fernhout.com> In trying to further think through what would be involved in supporting Squeak-like (or just Smalltalk-like) capabilities for Python in constructivist education, on reflection, I think the single biggest issue is that of the Squeak/Smalltalk "image". There are lots of other issues, but I am now thinking those are more easily solvable by just programming, often using existing Python libraries, than this one, which is more reflective of deeper issues. For those of you unfamiliar with the notion of a Smalltalk "image", it is essentially this: you can pick "save image" from your running Squeak environment and the whole running vm's object memory is saved to one file. Then when you start up Squeak and specify your image file, everything is back the way you had it when you saved (in theory) -- windows, open files, open socket connections, everything. In practice, open socket connections and open files sometimes can't be reopened (the port may be in use for a server socket, or a server may be down for a client socket), files may have been deleted or locked and so can't be reopened, a database may have changed, and so on. (And making this work under the covers can be non-trivial.) But, as least, the system tries to put everything back the way it was, and it almost always does a perfect job for plain GUIs. What's more, you can bring this file to any machine on any OS and processor that runs a fairly similar version of Squeak (like moving Mac/PPC to GNU/Linux/AMD64), and just start it up and you are back where you saved. And here is the key point: you get all this for "free" when you work with Squeak. You generally don't have to use a "pickle" library yourself, or write object saving and loading code for your windows, or do anything like that. It just works. Why is the image so important for the novice user in a constructivist educational setting? If a learner is learning by building, then it stands to reason that tomorrow they would like to learn by building on top of what they have already built more often then they would want to start from scratch. Starting from scratch can be a good learning experience, no doubt, but it gets old if you do it over and over again. So, when a learner can save their image and reload it tomorrow, they are exactly where they left off. So, if they are in the midst of building a simulation by dragging graphical widgets around, then they just save it, and tomorrow there it is. And here is they key: they never had to write any saving or loading code to do this. And neither did the author of the underlying package they are using. This is a big thing IMHO. It lets the learner focus more on what they are doing without the distraction of "how can I save and load this". Now, in practice, Squeak does save and load things outside the image. It uses files to store code, communicates over sockets, uses databases, and so on. In some ways, using an external file to save, say, your email seems much safer than storing it just in an image (which is a binary file and could easily get corrupted). To do that, an application has to use some explicit form of representing objects as text and reading them back in itself. If you want to share a small part of your image, like just the simulation you wrote, then it makes sense to be able to export that part (preferably as text) and share it (most smalltalk have some support for this equivalent to pickle or xml object writing). So the image isn't everything. But for the basics of where windows are, what widgets are in them, and what dynamic objects exist in the environment, it does a great job. So, where is the Python PySqueak problem? The graphics widget set is the biggest issue (sockets, files, databases, etc. are hard, but simpler). Smalltalk are designed from the ground up to do this. In Squeak's case, all the widgets are native, so their state is defined purely by Smalltalk objects. In other Smalltalk which use native widgets, the issues are thought through at the beginning on how the windows will be created and then recreated on reloading an image and that part is usually hidden from the user. And how to figure out what native GUI widgets are up on the screen and how to save that and reload it, all transparently to the user, is a non-trivial thing, and it varies from widget set to widget set. Since Python wants to be platform agnostic, and since there are a lot of widget sets out there (x, wx, tk, swt, swing, gtk, qt, mac flavors, mozilla and other web browser widgets, etc.), plus a lot of code written for them, that means a bit of a problem. I think in theory one could write widget set savers and reloaders that know enough about a specific widget set to walk the tree of displayed widgets and rebuild it. But, that is a lot of work that needs to be done for each widget set. And then, ideally, that all needs to work with existing widget using code not written to use a well designed library that hides these reloading problems. So, I think that would be the biggest issue to solve -- giving Python an image capacity. It doesn't have to be solved because one could always continue with the Python assumption that applications will be written to save and load their state. One could also build that into specific educational constructivist widget sets like an eToys clone. But it remains a mismatch in philosophy. This isn't a plug for C++, but consider: http://www.whysmalltalk.com/quotes/index.htm "Smalltalk is the best Smalltalk around" [on using C++ to code dynamic language idioms more appropriately done in Lisp or Smalltalk] - Bjarne Stroustrup Which is meant more or less as a reminder that languages have things they do well, and not so, well, and philosophies and communities built around them. So, while it is possible to ape Squeak Smalltalk in Python (including an image), is that worth doing? If you want everything Smalltalk (or Squeak) has to offer, then you can use Smalltalk (or Squeak) and live with other limitations (it's license, stability, and world view). I'm not sure there is that much value in reinventing that wheel. And it's also probably much easier to just put a Python parser into Squeak than reinvent Squeak on Python. So I continue to think what is interesting (and challenging) about the notion of a PySqueak is to try to understand what the core issues are that Squeak tries to solve (in this case, making it easy to save and load current state of an object system, including that of GUIs) and think of Python oriented approaches to do that. Again though, the notion of having a Python image could be rejected as a goal. Even Squeak does use external files for various tasks. When the outside world changes the inside world in the image gets out of date. More and more community-oriented applications (including Squeak's Croquet shared 3D world, but also others down to simple web applets or html forms) rely on storing state in outside servers or across peers and so need to reload from the network on startup anyway in practice. Keeping everything in one image mixes application and user data, and also often leads to an unmanaged growth in complexity as the image accumulates clutter. When the Squeak VM changes, one needs to clone the image into a new format, and in practice, end users aren't going to want to do that with their old images and just start over from scratch, filing and out code or application state. Squeak stores its source code history and other changes outside the image in a couple of text files (in part to rebuild the image if it crashes or gets corrupt). Even within the Squeak community, there are constant pressures to be able to build an image from a textual representation (something not trivial to do, and historically resisted by the main people in the project, perhaps out of sentimentality? or compassion? as the Squeak image has roots as a living thing back more than 20 years). However, even with pressure to be able to build an image from Scratch, something every Python program essentially does by running from *.py files, I'm sure almost no one in the Squeak community would want to lose saving and loading their current image. So anyway, that's the outline of one of the biggest Squeak->Python issues IMHO. And, I'd caution, it is one that is easy to dismiss as unimportant if you do not have experience working with images, the same way it is easy to dismiss something like garbage collection as unimportant if you are comfortable working in C++. Still, you can patch garbage collection onto C++ (in an awkward fashion) and one could probably patch images onto Python somehow (if that was desired). It's mostly a matter of considering how images interact with the Python glue philosophy, and also, in this case, in an educational constructivist setting, where I think saving state easily is a big win for everybody, especially in a classroom setting often with very short time periods for doing a bit of exploring and constructing, but potentially lots of them over the course of months. The default right now is every Python application must invent its own way of saving its state. So, should that be revisited? Or perhaps, this instead points to a need to improve pickle or create a community-wide widget reloading standard? It occurs to me, just now, at the end, as I revise this, what the Python way might be. :-) And it is to write its state as a Python text file! Something I need to muse over. :-) --Paul Fernhout Learning by writing. :-) From vceder at canterburyschool.org Thu May 4 16:25:19 2006 From: vceder at canterburyschool.org (Vern Ceder) Date: Thu, 04 May 2006 10:25:19 -0400 Subject: [Edu-sig] [Ann] DocTest solution: Crunchy Frog In-Reply-To: <7528bcdd0605032057v2c59df43s886457ba3a483163@mail.gmail.com> References: <7528bcdd0605032057v2c59df43s886457ba3a483163@mail.gmail.com> Message-ID: <445A0ECF.9030100@canterburyschool.org> Andre, This looks very promising. Things worked just fine for me except that on my system (Ubuntu Dapper) the browser is not at /opt/firefox/mozilla-firefox-bin Otherwise, it looks good. And personally, I *LIKE* the name "crunchy frog"... +1 ;) Vern Andre Roberge wrote: > Version 0.1 of Crunchy Frog has been released. It can be found at > https://sourceforge.net/project/showfiles.php?group_id=125834 > > Crunchy Frog allows to transform a "traditional" Python tutorial into > an interactive session within your favourite web browser. Three > "modes" of interaction are currently possible: > 1. one-liner, similar to the typical instruction at the Python interpreter. > 2. multi-line Python code, as entered in a traditional editor, and > executed by Python. > 3. Solutions to doctests, as described by Jeff Elkner in a previous post. > > Crunchy Frog is more of a proof-of-concept than a serious application > at this point. The code is rather messy, showing my total lack of > experience with this type of program (web app). To use it you will > also need to have installed Elementtree (included with Python 2.5?) > and CherryPy. You do not need to install Crunchy Frog. > > To try it: read the 5 (short) pages long "tutorial" included, using > your favourite browser. Then, start Crunchy Frog, and go through the > tutorial again. The whole thing should be doable in less than 10 > minutes. > > Andr? > _______________________________________________ > 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 From andre.roberge at gmail.com Thu May 4 16:32:47 2006 From: andre.roberge at gmail.com (Andre Roberge) Date: Thu, 4 May 2006 11:32:47 -0300 Subject: [Edu-sig] [Ann] DocTest solution: Crunchy Frog In-Reply-To: <445A0ECF.9030100@canterburyschool.org> References: <7528bcdd0605032057v2c59df43s886457ba3a483163@mail.gmail.com> <445A0ECF.9030100@canterburyschool.org> Message-ID: <7528bcdd0605040732y48e7b832o1a0033d796f78618@mail.gmail.com> On 5/4/06, Vern Ceder wrote: > Andre, > > This looks very promising. Things worked just fine for me except that on > my system (Ubuntu Dapper) the browser is not at > /opt/firefox/mozilla-firefox-bin Thanks for the feedback. I'll have to investigate; I just used CherryPy and webbrowser's methods *as is* and it worked fine for me- so I never had any reason to question it. > > Otherwise, it looks good. > > And personally, I *LIKE* the name "crunchy frog"... +1 ;) > It's growing on me too! Andr? > Vern > From francois.schnell at gmail.com Thu May 4 17:15:14 2006 From: francois.schnell at gmail.com (francois schnell) Date: Thu, 4 May 2006 17:15:14 +0200 Subject: [Edu-sig] New version "TNG" of StarLogo ( 3D & Visual & Blocks) Message-ID: <13a83ca10605040815k12086ca8m23b6716936d513ab@mail.gmail.com> Hello, In the "visual programming" theme, I've just seen that a new 3D and visual (though blocks) version of StarLog is available (a preview version now and a 1.0 this summer): http://education.mit.edu/starlogo-tng/ Some screencasts: http://education.mit.edu/starlogo-tng/tutorial-videos/ It's written in Java :( and the FAQ says this about the licence: ----- *Is StarLogo TNG open source? Can StarLogo TNG be open source?* StarLogo TNG is free for educational use, but it is not currently open source. We are considering an open source license in the future, but internal licensing issues and resources will determine that schedule. The previous version of StarLogo is being released soon under an open source license. ---- And the difference with Scratch: --- What is the difference between Scratch and StarLogo TNG? Both Scratch and StarLogo TNG share a common heritage with LogoBlocks, a tool to create programs for Crickets. The two tools are written from entirely separate code, but we do share ideas. The audiences are different for the two products as well. Scratch is primarily designed as a tool to make computational multimedia projects for kids, targeted at Computer Clubhouses. StarLogo TNG is designed for more formal education environments such as introductory programming classes, or subjects (such as biology, chemistry, physics, etc.) where modeling is an important part of the curriculum. They're both interesting tools, and you should check out Scratch when it becomes available. Scratch is built on Squeak. http://llk.media.mit.edu/projects/#scratch ---- francois -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20060504/1d981247/attachment.html From ianb at colorstudy.com Thu May 4 18:40:38 2006 From: ianb at colorstudy.com (Ian Bicking) Date: Thu, 04 May 2006 11:40:38 -0500 Subject: [Edu-sig] [Ann] DocTest solution: Crunchy Frog In-Reply-To: <445A0ECF.9030100@canterburyschool.org> References: <7528bcdd0605032057v2c59df43s886457ba3a483163@mail.gmail.com> <445A0ECF.9030100@canterburyschool.org> Message-ID: <445A2E86.9020102@colorstudy.com> Vern Ceder wrote: > Andre, > > This looks very promising. Things worked just fine for me except that on > my system (Ubuntu Dapper) the browser is not at > /opt/firefox/mozilla-firefox-bin Huh, on Ubuntu the webbrowser module works fine for me out of the box. Do you maybe have something in /opt/firefox that could distract the module? It shouldn't run the -bin directly either. It looks like it just runs "mozilla-firefox -noraise|-raise remote 'openURL([,new-window])'", and leaves it up to PATH to find the actual binary. -- Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org From andre.roberge at gmail.com Fri May 5 04:31:32 2006 From: andre.roberge at gmail.com (Andre Roberge) Date: Thu, 4 May 2006 23:31:32 -0300 Subject: [Edu-sig] [Ann] DocTest solution: Crunchy Frog In-Reply-To: <7528bcdd0605032057v2c59df43s886457ba3a483163@mail.gmail.com> References: <7528bcdd0605032057v2c59df43s886457ba3a483163@mail.gmail.com> Message-ID: <7528bcdd0605041931n2a43e564s442ac394a9b2e5a9@mail.gmail.com> Version 0.2 of Crunchy Frog is ready to be released. After refactoring the code in a major way, I have been able to implement *almost* all the non-graphical features I was hoping for. The code should now be very easy to understand, if you have some familiarity with CherryPy and ElementTree. Unfortunately, sourceforge appears to have been down for a while, so I haven't been able to upload it. If you want to try it, and can`t find it on sourceforge, feel free to contact me by email and I'll send you a copy. The updated 5 html files and 3 Python files fit in less than 10 kB (zip file). When you enter some Python code in an "editor area" and have Python execute the code, the code no longer disappear from the "editor area". This is the most important improvement, from a usability point of view. You can now also have an arbitrary combination of 'fake interpreter prompt', 'editor area' and 'DocTest areas' on a single page. The code that takes care of the execution of the user code has been extracted and put in a small module on its own. Therefore, whenever one develops a "Python sandbox", it will be extremely simple to make use of it. There are three main features left to implement: 1. add the possibility to load "non-local" html files. This might be as easy as adding a couple of lines of code, using a module like urllib. When I figure out how to do that, I'll be pestering authors of existing Python tutorials to adapt them for use with Crunchy Frog ;-) 2. Fix a major annoyance for "long" pages: at present, when executing a code snippet, the page gets reloaded at the very top, even if the "editor area" or "fake interpreter prompt" was at the bottom of the page. I haven`t been able to find out how to do this using CherryPy. 3. Being able to navigate in an arbitrary directory structure. Up until now, I have had problems if the html files were not all in a single directory. There are a few other features (like saving a session) that I would like to ideally fix before version 1.0. The usage I make of CherryPy appears to be extremely minimal. I suspect that someone familiar with web programming using the standard library would be able to reproduce what I did without too much programming efforts. If anyone has any pointers as to how I could do this, I would appreciate it. As usual, any feedback including strong criticisms are welcome! Andr? On 5/4/06, Andre Roberge wrote: > Version 0.1 of Crunchy Frog has been released. It can be found at > https://sourceforge.net/project/showfiles.php?group_id=125834 > > Crunchy Frog allows to transform a "traditional" Python tutorial into > an interactive session within your favourite web browser. Three > "modes" of interaction are currently possible: > 1. one-liner, similar to the typical instruction at the Python interpreter. > 2. multi-line Python code, as entered in a traditional editor, and > executed by Python. > 3. Solutions to doctests, as described by Jeff Elkner in a previous post. > > Crunchy Frog is more of a proof-of-concept than a serious application > at this point. The code is rather messy, showing my total lack of > experience with this type of program (web app). To use it you will > also need to have installed Elementtree (included with Python 2.5?) > and CherryPy. You do not need to install Crunchy Frog. > > To try it: read the 5 (short) pages long "tutorial" included, using > your favourite browser. Then, start Crunchy Frog, and go through the > tutorial again. The whole thing should be doable in less than 10 > minutes. > > Andr? > From pdfernhout at kurtz-fernhout.com Fri May 5 09:46:27 2006 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Fri, 05 May 2006 03:46:27 -0400 Subject: [Edu-sig] PySqueak: "Self" as the source of many ideas in Squeak Message-ID: <445B02D3.7060504@kurtz-fernhout.com> In continuing to contemplate what are the essential ideas of Squeak in terms of using them in an educational environment resting on Python, I decide to revisit some of Squeaks' roots. Many of these are in "Self", a prototype based programming language (and IMHO a constructivist one too). The main page for Self: http://research.sun.com/self/language.html I had read of Self, and met one of the key people once at a conference, and I was inspired by many ideas from those interactions, as well as work with NewtonScript (the native programming language of the Newton, also inspired by Self), but I had never seen the Self system in action. It turns out there is a 15 minute or so video on Self, linked to from here: http://www.merlintec.com:8080/Self Kirby, you mentioned the persuasive power of videos in another context, and I suggest viewing the high definition version of the videos there would be useful in seeing how a graphical environment for students could approach the immediate feedback of the command line, especially with most of today's students who are presumably already "point and click" mouse literate. The key principles mentioned in movie for Self's design are based on ideas from the physical world, and are summarized as: * Directness (everything is potentially visible and touchable) * Uniformity (you can consistently change everything) * Modelessness (always running, so no editing/running distinction) Self also demonstrates multiple people doing activities together in one (2D) environment. [BTW Neometron's Learningworks was about 3D communities using Smalltalk and was deployed a decade ago, which shows some other roots of Squeak/Croquet roots here.] From the paper here (first seen in a link below): http://research.sun.com/self/papers/programming-as-experience.html "Finally, in designing Self, we have learned one lesson by making mistakes: examples can persuade the designer to include additional features which later turn out to produce incomprehensible behavior in unforeseen circumstances. This might be called the language designer's trap. Minimalism, simplicity and consistency are better guides. They benefit every programmer, not just the ones who need advanced features. We suspect that many of today's object-oriented languages could profit by dropping features." In my own work in Smalltalk development, knowing that Self existed, and having experience with prototypes in Newtonscript, I was often frustrated by Smalltalk not having Self's elegance. And I think many of the issues Self addresses (particularly eliminating a class side / instance side distinction) are very important to making programming easy to get into, as well as keeping it more fun. In the movie near the end they make the distinction between telling objects what to do (writing code) and just banging them around into position (which Self's GUI helps support, in addition to programming). By building in "Morphic" (the Self GUI paradigm) Squeak tries to get this Self leverage, but I think, given Squeak's use of Smalltalk (which has classes), Morphic always seemed to me to be rather inelegantly bolted on (this is not a slam at the developers, just an inherent problem of a class based programming system trying to work with dynamic constructivist material). One of the things I have always liked about Python is its use of dictionaries for storing values in instance objects. This is computationally inefficient compared to looking up things by position in an array as C or Smalltalk do, but it is more flexible in terms of taking any specific instance and adding more data fields to it, so it is efficient in a human-oriented way and can lend itself somewhat to this sort of prototype based work. So, another idea when thinking about PySqueak is: how can Python better support prototype based development? As well as: how can what we have with Python2.4/Jython2.1 now be used to do that in interesting ways? Now this certainly isn't a new idea, see for example these discussions: http://lists.canonical.org/pipermail/kragen-hacks/2000-September/000264.html http://www.thescripts.com/forum/thread30832.html http://www.prothon.org/ http://www.google.com/search?hl=en&q=Prothon or Prothon's apparent successor, PyCS: http://www.prothon.org/pipermail/prothon-user/2004-August/003269.html http://pycs.org [However, the Prothon and Pycs links seem to be down right now, I read them through the Google cache just now as this project is new to me, perhaps an indication the project is ended?] These three key principles above, relating to a dynamic nature of the Self system, are probably needed to support any constructivist approach to software creation and use. But notice how they are the opposite of the principles behind something like C++ or other statically typed languages, which focus on data hiding, specialized interfaces, and set-in-stone compiled applications. Or as Alan Kay put it: http://www.smalltalk.org/articles/article_20040731a.html "I invented the term Object-Oriented, and I can tell you I did not have C++ in mind." This statically compiled approach culminates brilliantly in something like OCaml, http://en.wikipedia.org/wiki/Ocaml since if you want types with the least pain and syntactic clutter, OCaml can infer many of them for you. C++ or OCaml are pretty much about specifying everything in advance and locking down the system, assuming it will never change at runtime, to get the most out of memory and computer cycles focused on a narrowly defined fixed problem. This is not to say C++ or OCaml can't be used to make open systems (say, by defining a Smalltalk or Common Lisp or Python virtual machine in some way), but openness at runtime is clearly not what those languages are about. Now there are places for that sort of efficient and effective closedness, but it is a very different philosophy from creating open systems like Self, or Squeak. Python clearly potentially can be used in a Self-like or Squeak-like open way, and some core development tools rely on that, but in practice most of the time Python seems not to be used that way. Perhaps this is due to, as a speculation, that most people come to Python from a C/C++ background, which is why they liked the "f(a, b, c)"-style syntax as opposed to keywords (Smalltalk) or lots of parens (Lisp). Clearly, if most Python development had a long legacy of being oriented around that sort of open and dynamic constructivist principle, with the size of the Python community and its technical skill, we would probably already have a dynamic environment better than Squeak for all the things Squeak does. :-) So, as I reflect on this, the roots of not having Squeak on Python *already* may have more to do with Python community culture and history and mindset than Python limitations. One can of course hope that a successful PySqueak project in that direction will prove to be a "better mouse trap" and the Python community will flock to it, although that may not be realistic, speculating about the Prothon and PyCS sites being down. And as it pointed out here by Sjoerd Visscher: http://lambda-the-ultimate.org/classic/message11653.html "Flexibility is nice, but useless when the libraries are implemented in one programming style. That programming style will be the only natural style of the language." I want to underscore and emphasize this difference between these two philosophies of programming language design, because it seems that the directions proposed for mainstream Python, if anything: http://www.artima.com/weblogs/viewpost.jsp?thread=86641 have been in directly the opposite direction to Self, to a Python with static typing (including RPython). So, frankly, there very well simply be an insurmountable cultural barrier here. And there is nothing wrong with that -- static types are a valid way to generate code that efficiently uses memory and computation to solve a specific well defined purpose (like a well specified Python VM or any other well specified problem). However such a focus will remain at odds as far as I can see with the notion of a living and evolving population of objects system, which is at the core of a constructivist vision of education or programming. Hopefully a diverse Python community could productively use both paradigms in language variants, so an RPython for certain specific tasks, and a proto-Python for everything else (or at least, some forms of educational use)? Unfortunately, the more one sees a path diverging from Python as it is commonly defined (towards, say, a Prothon? direction) the quicker interest in a PySqueak will evaporate, if it has not already. :-) Because then it is just some quirky side variant. Still, there are niches in the Python community, like with Jython, where a slight change in direction may be more feasible, at the very least as a proving ground of sorts (Jython sometimes has its own identity crisis of whether to track CPython or strike out on its own, usually resolved in favor of tracking.). So, again, in thinking what Squeak on Python might mean, as opposed to aping Squeak, Python could build on its strength of using dictionaries internally and support a more prototype based environment like what Prothon or PyCS tried to move towards, making it more similar to Self than the derivative (in that sense) Squeak (which still uses classes). Coupled with a self-like GUI, I think that would better support constructivist educational needs. Of course, then one can ask, is this just reinventing the Self wheel and is that worth doing (to potentially gain Python community advantages, which might be questionable if the approach deviated in any significant way from mainstream Python)? It would seem clearer that the most leverage would be gained if Python (or Jython) as it is now (or with at best trivial changes) could be used to support Self-like features, and thus realize some of the constructivist ideals also embodied and further popularized in Squeak. Or, as Ian Bicking points out here in "Initial thoughts on Prothon": http://www.artima.com/forums/flat.jsp?forum=122&thread=41588 "[After mentioing Prothon syntax changes from Python...] I actually wonder to what degree prototypes could be implemented in Python with metaclasses. While some of the syntax would currently be crufy with Python (e.g., you'd have to create a function, then assign the function to an object), that's kind of a separate issue. The bpython metaclasses asic object model in Python feels like it should be replaceable, especially since we already have both new and old style classes. I think it's still a bit hard to think about these with the syntax getting in the way or otherwise being distracting, but feel like the potential is in there somewhere. If it could be hacked onto Python instead of developed entirely separately from Python, it could make Prothon much more interesting from the perspective of practical programming. Ultimately it would probably have to be like Stackless -- a patch against Python implementing some necessary changes to syntax. But that's a more viable development effort, and one that's more likely to percolate ideas into the main Python interpreter." I think that Ian's suggestion is the most sensible strategy for proceeding in that direction and continuing to maintain community interest in a PySqueak inclined towards Self-like prototypes and a related GUI for constructivist educational use (and other general use as well). And if metaclasses turn out to not be the best approach, still anything simple which preserves the Python syntax while giving the new features (say, having all prototypes inherit from a common class which overrides __getattr__ and __setattr__ to simply look into the instance to find data and behavior?) Ian, any recent thoughts on that? I would speculate that part of the general interest of the world in HyperCard was that it to some extent worked in a direct-manipulation protype-based way. Perhaps that similarity resonates with you as well? --Paul Fernhout From andre.roberge at gmail.com Fri May 5 13:10:21 2006 From: andre.roberge at gmail.com (Andre Roberge) Date: Fri, 5 May 2006 08:10:21 -0300 Subject: [Edu-sig] Crunchy Frog (almost) ready for classroom use. Message-ID: <7528bcdd0605050410r4c691d26se74c39bc6ca0bb6d@mail.gmail.com> The wonders of a good night sleep... Version 0.2.5 of Crunchy Frog has been release and is on sourceforge at the usual place (link below in this message). [snip] > > There are three main features left to implement: > > 1. add the possibility to load "non-local" html files. This might be > as easy as adding a couple of lines of code, using a module like > urllib. When I figure out how to do that, I'll be pestering authors > of existing Python tutorials to adapt them for use with Crunchy Frog > ;-) > > 2. Fix a major annoyance for "long" pages: at present, when executing > a code snippet, the page gets reloaded at the very top, even if the > "editor area" or "fake interpreter prompt" was at the bottom of the > page. I haven`t been able to find out how to do this using CherryPy. > This has been fixed. > 3. Being able to navigate in an arbitrary directory structure. Up > until now, I have had problems if the html files were not all in a > single directory. > [snip] > On 5/4/06, Andre Roberge wrote: > > Version 0.1 of Crunchy Frog has been released. It can be found at > > https://sourceforge.net/project/showfiles.php?group_id=125834 > > > > Crunchy Frog allows to transform a "traditional" Python tutorial into > > an interactive session within your favourite web browser. Three > > "modes" of interaction are currently possible: > > 1. one-liner, similar to the typical instruction at the Python interpreter. > > 2. multi-line Python code, as entered in a traditional editor, and > > executed by Python. > > 3. Solutions to doctests, as described by Jeff Elkner in a previous post. > > From pdfernhout at kurtz-fernhout.com Fri May 5 16:19:25 2006 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Fri, 05 May 2006 10:19:25 -0400 Subject: [Edu-sig] PySqueak: "Self" as the source of many ideas in Squeak In-Reply-To: <445B02D3.7060504@kurtz-fernhout.com> References: <445B02D3.7060504@kurtz-fernhout.com> Message-ID: <445B5EED.3030706@kurtz-fernhout.com> Paul D. Fernhout wrote: > Or, as Ian Bicking points out here in "Initial thoughts on Prothon": > http://www.artima.com/forums/flat.jsp?forum=122&thread=41588 > [with quoted text from Ian which had "python metaclasses\n" > pasted in it by me by mistake.] Ian- Sorry to mangle your eloquent writing by accidentally pasting "python metaclasses" in the middle of it (up till 4am writing inspired by seeing the Self video, sorry). --Paul Fernhout From kirby.urner at gmail.com Fri May 5 18:09:33 2006 From: kirby.urner at gmail.com (kirby urner) Date: Fri, 5 May 2006 09:09:33 -0700 Subject: [Edu-sig] PySqueak: "Self" as the source of many ideas in Squeak In-Reply-To: <445B02D3.7060504@kurtz-fernhout.com> References: <445B02D3.7060504@kurtz-fernhout.com> Message-ID: On 5/5/06, Paul D. Fernhout wrote: <> > So, as I reflect on this, the roots of not having Squeak on Python > *already* may have more to do with Python community culture and history > and mindset than Python limitations. Constraints provide form and allow function. I'm thankful that Python has the heritage Guido gave it: easy to learn if you're an adult in a late 1900s technical mindset, already working around computers, probably already knowing some C (but finding it slow going and unproductive). Python made it easier for astronomers, health professionals, statisticians, engineers to get work done in a computer language. That's a fine place to start, no apologies needed. I go back to my view that a powerful 3D graphics engine is something many languages would like to use and there's no reason the Python community should shoulder the entire developmental effort. Establish a common low level API that lots of languages might use. Such a 3D engine is for data visualization and simulations, but also for storyboarding and puppet shows -- not unlike Blender in some ways. We have cameras (points of view) and shapes with behaviors and attributes, coordinate systems. A single Python script could set up the scene and carry us through a story about a White Monkey. I'm reminded of a Pycon demo in DC, where we saw a simulator and language trainer used for English speakers going to Iraq. Unreal Tournament 3000 was the game engine. Python bindings had been established... Suddenly, we were in the outskirts of Baghdad, encountering Iraqis lolling around a coffee shop in a somewhat destroyed landscape. The dialog was basically: "Hello [polite introductions] who is your leader and how can we find him?"; detailed instructions provided [left, right, left, straight...]; following instructions; finding and greeting leader [politely]. That's if all went well. At every decision point, trainees might experience Game Over, perhaps because of intonation. A speech analyzer on the other end of the microphone contained algorithms looking for intelligible Arabic. Anything less was unacceptable. Kirby From ianb at colorstudy.com Fri May 5 18:22:15 2006 From: ianb at colorstudy.com (Ian Bicking) Date: Fri, 05 May 2006 11:22:15 -0500 Subject: [Edu-sig] PySqueak: "Self" as the source of many ideas in Squeak In-Reply-To: <445B02D3.7060504@kurtz-fernhout.com> References: <445B02D3.7060504@kurtz-fernhout.com> Message-ID: <445B7BB7.70609@colorstudy.com> Paul D. Fernhout wrote: > The key principles mentioned in movie for Self's design are based on ideas > from the physical world, and are summarized as: > * Directness (everything is potentially visible and touchable) > * Uniformity (you can consistently change everything) > * Modelessness (always running, so no editing/running distinction) > Self also demonstrates multiple people doing activities together in one > (2D) environment. [BTW Neometron's Learningworks was about 3D communities > using Smalltalk and was deployed a decade ago, which shows some other > roots of Squeak/Croquet roots here.] This is a little of what I intend with HTConsole; the objects are (vaguely) live, and potentially shared. Though I've only implemented useful liveness for functions so far. It's at conflict with the idea of source code, and live objects really require an image, and I've never liked images. So I'm not sure if it's a useful path. > Now this certainly isn't a new idea, see for example these discussions: > http://lists.canonical.org/pipermail/kragen-hacks/2000-September/000264.html > http://www.thescripts.com/forum/thread30832.html > http://www.prothon.org/ > http://www.google.com/search?hl=en&q=Prothon > or Prothon's apparent successor, PyCS: > http://www.prothon.org/pipermail/prothon-user/2004-August/003269.html > http://pycs.org > [However, the Prothon and Pycs links seem to be down right now, I read > them through the Google cache just now as this project is new to me, > perhaps an indication the project is ended?] As far as I know, the project fizzled soon after the move to CLR was announced. > I want to underscore and emphasize this difference between these two > philosophies of programming language design, because it seems that the > directions proposed for mainstream Python, if anything: > http://www.artima.com/weblogs/viewpost.jsp?thread=86641 > have been in directly the opposite direction to Self, to a Python with > static typing (including RPython). I wouldn't put too much weight on this, especially RPython. RPython isn't meant to compete with Python in that way. And it is Squeaky in its own way. > Or, as Ian Bicking points out here in "Initial thoughts on Prothon": > http://www.artima.com/forums/flat.jsp?forum=122&thread=41588 > "[After mentioing Prothon syntax changes from Python...] > I actually wonder to what degree prototypes could be implemented in > Python with metaclasses. While some of the syntax would currently be crufy > with Python (e.g., you'd have to create a function, then assign the > function to an object), that's kind of a separate issue. The basic object > model in Python feels like it should be replaceable, especially since we > already have both new and old style classes. I think it's still a bit hard > to think about these with the syntax getting in the way or otherwise being > distracting, but feel like the potential is in there somewhere. If it > could be hacked onto Python instead of developed entirely separately from > Python, it could make Prothon much more interesting from the perspective > of practical programming. Ultimately it would probably have to be like > Stackless -- a patch against Python implementing some necessary changes to > syntax. But that's a more viable development effort, and one that's more > likely to percolate ideas into the main Python interpreter." Some things other people have done (like Logix: http://livelogix.net/logix/) makes me think that this could be done in CPython now, with just some fiddling in the compile process. I think the Python object model (which can't easily be changed) is already flexible enough for this. And ignoring some syntactic details you could do this in current CPython. > I think that Ian's suggestion is the most sensible strategy for proceeding > in that direction and continuing to maintain community interest in a > PySqueak inclined towards Self-like prototypes and a related GUI for > constructivist educational use (and other general use as well). > And if metaclasses turn out to not be the best approach, > still anything simple which preserves the Python syntax > while giving the new features (say, having all prototypes inherit from a > common class which overrides __getattr__ and __setattr__ to > simply look into the instance to find data and behavior?) I think it could be easier than that. I think a lot of the more declarative programming I do really has prototypes underneath it. (Ironically in Javascript I never find a need for prototypes, except to simulate classes.) An example: class Person(SQLObject): name = StringCol(notNull=True) I think Person.name is really best represented as a prototype. I've played around with using this: class Person(SQLObject): class name(StringCol): notNull = True As an equivalent operation -- it starts looking better when you add methods to the object (e.g., on_delete, on_update, etc). Actually having Person.name be a class is annoying, but you can get class statements to generate instances with some appropriate hackery. At that point you start blurring the distinction between class and instance. So, in this model, clone is the basic operation. I.e.,: class obj(prototype): a = 1 Means something like: obj = prototype.__class__() obj.__dict__.update(prototype.__dict__) obj.a = 1 (The actual mechanics require some dumb fiddling with fake metaclasses.) This is different from the delegation of a typical prototype language (where the prototype isn't copied, but is called back to), but it's fast and uses normal Python. And I guess with clone in a prototype language you are basically doing this copy? I'm more comfortable with copies than chains of delegation. There was a proposal recently for a "make" syntax in Python (http://www.python.org/dev/peps/pep-0359/), so this would look like: make prototype obj: a = 1 And the exact semantics would be something like: obj = prototype('obj', (), {'a': 1}) Or my preference: obj = prototype.__make__('obj', {'a': 1}) Sadly Guido rejected it. I think it's a much better syntax with cleaner semantics for this kind of case, and I think this kind of case is actually extremely common. The whole Lisp S-Expr stuff is about this kind of declarative data structure, and adding that to Python just requires this little tweak of the language; it doesn't give Python macros, but the way Lisp uses data structures is for much more than just macros. Smalltalk doesn't have anything like Lisp either, but uses live objects to some similar effect, which is what binds it to the image. > Ian, any recent thoughts on that? I would speculate that part of the > general interest of the world in HyperCard was that it to some extent > worked in a direct-manipulation protype-based way. Perhaps that similarity > resonates with you as well? I'm not really sure how to fit HyperCard into this -- I don't have a strong feel for what it really means. I suppose one aspect is that the source code is not at the core; instead the card stack is (or whatever content-centric metaphor you use), and code is attached there. Ad hoc structured code doesn't work that well with a class... you get something like: class Foo: def bar(self)... foo = Foo() And the class/instantiation is just a kind of boilerplate. OTOH, modules are another model; if each content-context (aka card) was a module, you get some of the structure without the conceptual overhead of the class. -- Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org From pdfernhout at kurtz-fernhout.com Fri May 5 19:00:01 2006 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Fri, 05 May 2006 13:00:01 -0400 Subject: [Edu-sig] PySqueak: more on the cultural divide among paradigms Message-ID: <445B8491.9070802@kurtz-fernhout.com> In discussing with my wife some of the ideas of my previous post (on "Self" as the source of many ideas in Squeak) a greater clarity has emerged for me on a programming paradigm issue (in large part due to her input related to her own related experiences with some people resisting prototype-style approaches in application design and others embracing them). Our best Physics and Psychology (taken together, as interpreted by me :-) right now suggests the universe is a sea of subatomic particles in relation to each other in complex ways (determining how those relations change in the future). "Objects" (and Platonic "classes" for objects) are fictions our mind uses to try to make sense of all that complexity. So too, the notions of "class" and "objects" are fictions we programmers invent to get a handle on the raw sea bits of computer memory as they change over time from computational rules applied to them. But they are also fictions we try to apply to the real world when we write accounting systems as well. And they often break down, as illustrated in depth in the late William Kent's book _Data and Reality_. http://www.bkent.net/ We often use the term "Abstraction" to point at this problem (or even cover it up), but that doesn't capture the whole notion, since it that word is often used with the intent that there is one abstraction, as opposed to the notion that the abstraction is just one possibility we chose because it was useful at the moment for specific human goals. So, as far as computer language paradigms go (and teaching people about them), there are then two sets of issues. One relates to modeling the "real world" (because computers are often used to do that) and one relates to getting a handle on "telling the computer what to do" (because you can't do the first without the second). These are somewhat related issues (after all, we are in some sense building models of the real world even when they are about programs running on VMs), though they are still distinct issues in my mind. In terms of increasing levels of computing machinery, we have something like: Machine -> Assembly -> Functions -> Classes -> Prototypes -> Relations In terms of world modeling done by a human mind about the world, we have somewhat the reverse, in: Classes -> Objects(Prototypes) -> Relations -> Reality [Kent outlines an idea for a relation programming system called ROSE or STAR, and I have worked towards something similar in my Pointrel ideas, but the common metaphor is an "entity-relational" model of data). http://en.wikipedia.org/wiki/Entity-relationship_model There of course may be other levels, or even a branching tree, and one might organize these differently, if say, you build a Smalltalk on top of Self, so this is all a big simplification to get one started thinking about this issue. Simplifying greatly even further, it has been the history of computing to move away from the machine to what is often called "higher levels" of abstraction. While it has been the history of (western) Physics to drill ever deeper into the notion of perceptions of reality starting from the perception of Platonic ideals (or classes). Integrating perceptions across these levels is not that easy. Forth does is somewhat for computing though IMHO, a tiny language that can easily be extended to support various paradigms. And here is the cultural divide: when a person is at one level of understanding of all this, it is very hard to convince them of the value or even feasibility of the other levels they may have no experience with. This notion is inspired somewhat by my reading "Future Shock Levels" by Eliezer S. Yudkowsky: http://yudkowsky.net/sing/shocklevels.html "The use of this measure is that it's hard to introduce anyone to an idea more than one Shock Level above - and Shock Levels measure what you accept calmly, not what you know about.") But clearly thinking about levels of understanding is a common teacher-type curriculum design thing to do. And, these other levels may (at least initially) impose discouragingly large cognitive and computational burdens to try out. So, it is just very hard to get someone used to thinking hierarchically about classes of birds that such distinctions are somewhat arbitrary if you truly understand taxonomic issues. Or further, that the very notion of a specific individual bird is a convenient fiction the mind invented for surviving in and making sense of the universe (instead of modeling the bird and its environment at a horrendously detailed quantum level, plus modeling the minds goals in such a way if such was possible). Or, looking at this issue from programming point of view, one can implement Classes in C, but they seem slower for the standard problems C is used to solve. Or one can implement Morphic and prototypes in Smalltalk, but they feel like a kludgey add on. Or one can implement relations with prototypes, but they will certainl at first seem inelegant and slow. [As an aside, I have a prototype of a Smalltalk-like VMs in C and Python that uses a entity-relational model of triads of data for their cores; inefficient yes, but elegant IMHO, and it turns out easy to reach into remotely, or have one simple unified browser to study system state, or be able to imagine the system running backwards for debugging.] There may also even be a personality effects related to feelings about authoritarianism and control, or where one falls on the "meshwork vs. hierarchy" preference landscape. http://www.t0.or.at/delanda/meshwork.htm For a (personal example), having some Dutch roots myself, yet being an outsider to Holland, I can see in that culture a paradox of both pride and success in being a permissive society, while at the same time pride and success in being a society influenced by some fairly strict religious ideals (including compassion) as well as pressures towards conformist behaviors. (This is true of all societies to some extent, but walking around Amsterdam is a very graphic example of this. :-) Or as is said in the intro to "The Portable Henry James" edited by John Auchard (my wife is reading it; I just glanced at it. :-): http://www.amazon.com/gp/product/0142437670/103-1147318-5179869?v=glance&n=283155 "The divide between a culture of individual freedom and a culture of tradition -- H.G. Wells identified communities of will, and communities of faith and obedience -- is a great divide, and it is a persistent and deep one in Henry James, as it should be, even though many Americans in the novels scarcely seem to notice. In the tales and novels it often is the exact place where things tear asunder, a place of broadly political crisis that stubbornly refuses reconciliation -- at least without the virtual annihilation of one side or the other". Beyond how this currently effects Dutch politics relating to immigration and integration issues, I think that factor is at play somewhat in Python's evolution too -- as the Python community is IMHO one that, with Pythons success in gaining broad interest, is currently struggling to reconcile both supporting a desire for prototypes and a desire to move in a strict static typing direction. :-) It's hard to do all these ideas justice in a few word, and I've probably lost many people trying to follow this by now who firmly believe objects really do exist they way they see them, but suffice to say, Python right now sits somewhat straddling the boundary between modeling data as classes and prototypes. Squeak is also at that boundary, less so as a language, but more so as a library and environment when it tries to patch Morphic prototype widgets on top of Smalltalk classes. So, in terms of moving PySqueak forward, the question is, whether to try to push a little like Squeak does, or to push even further, like on to entire prototype systems or even relational systems. Python has better support for prototypes than conventional Smalltalk since Python already uses a dictionary for instance variables as opposed to Smalltalk which uses an array of slots where the slot<->name correspondence is managed by a class. So if Python were to gain something like Morphic widgets, they would probably fit much more nicely into Python than they ever would on Smalltalk. (Ignoring the dominant paradigm determined by library code issue mentioned previously.) Still, Python doesn't try to do a entity-relationship model directly. So, one can ask, is it worth trying to do as Squeak specifically does (Morphic), or try to see the higher ideal of Squeak pushing up another level (Classes -> Prototypes), and try to go it one better (Prototypes -> Relations)? The Self video shows that once you do have a working prototype based system, making a Smalltalk with classes is fairly easy, and what more, actually runs faster than a typical Smalltalk. So too, perhaps a successful entity-relational language might be able to do prototypes easily and more quickly? In the triadal systems I work on (essentially a long list of items which are three pointers: P1 P2 P3) and a few operations on that, http://www.kurtz-fernhout.com/pointrel/ prototypes and classes merge naturally as useful approaches to many problems. But obviously, such a push risks drifting much further from any unifying vision driving interest in something like PySqueak, yet at the same time, it is less "reinventing the wheel", and more "burn the disk packs" to go beyond full steam ahead. At least in my own explorations of computation, trying to make systems that are more entity-relational has been what I have for two decades felt driven towards, informed by a certain conception of Physics and Psychology. But, the new insight from me is to see these two spectrums of (again): Machine -> Assembly -> Functions -> Classes -> Prototypes -> Relations and: Classes -> Objects -> Relations -> Reality and how human personality and cultural and economic pressures help determine individual choices about where to program and think on these spectrums. It's not an easy thing to wrestle with. Yet, as I learned from one smart person who had studied the patent literature, innovative progress comes from a successful attempt to reconcile seemingly opposing needs both at the same time (e.g. cheap and fast), rather than just compromise between them (e.g. cheaper but slower -- compromise being just engineering, or politics, as usual). As far as I am concerned, Squeak was a step backwards from Self in many ways (while forward in others, especially marketing and adoption-wise in an educational setting), as Self elegantly reconciles needs for prototypes and classes in a way that Squeak Smalltalk compromises with. Will PySqueak be a compromise or an innovation (or both)? It remains to be seen. Trying to keep this short, but failing. :-) --Paul Fernhout From pdfernhout at kurtz-fernhout.com Fri May 5 19:27:18 2006 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Fri, 05 May 2006 13:27:18 -0400 Subject: [Edu-sig] PySqueak: "Self" as the source of many ideas in Squeak In-Reply-To: <445B7BB7.70609@colorstudy.com> References: <445B02D3.7060504@kurtz-fernhout.com> <445B7BB7.70609@colorstudy.com> Message-ID: <445B8AF6.7050200@kurtz-fernhout.com> Ian Bicking wrote: > Paul D. Fernhout wrote: > This is a little of what I intend with HTConsole; the objects are > (vaguely) live, and potentially shared. Though I've only implemented > useful liveness for functions so far. It's at conflict with the idea of > source code, and live objects really require an image, and I've never > liked images. So I'm not sure if it's a useful path. Ian- Thank you for your detailed reply and I promise more thought on it, but on this one issue, to respond immediately, consider my earlier comments on images and the muse as to a potential "Pythonic" resolution. Basically, it is to think of the Python *image* as being defined by a Python *program* that builds an object world and is stored in a textual *.py file, and just looks and acts like regular Python source code -- ideally with comments preserved too. So, no pickled objects, not binary image files, just Python source code as readable text that rebuilds hierarchies and meshworks of objects. Or, as I realized shortly afterwards, perhaps an "python image" would be nto jsut one *.py file, but a whole bunch of *.py files in a directory, some of which might be more about defining classes (when you program that way) and some of which are about defining specific in-use instances. So, the Python image saving system might use the existing tagging of Python objects back to file names, for example (perhaps with some extensions needed). This way, a "save image" essentially would rewrite your directory of source. A bit scary perhaps, but with subversion or such not too risky perhaps. And not that different in some ways from what a tool like BoaConstructor does (or attempts to do). And other round trip GUI development systems (like Delphi) do this as well to varying degrees. The key difference of this approach might be that you were not usually editing the textual Python files in that directory by hand, but rather were using constructivist HyperCard and self-like tools to modifying a running Python program. Only then would you save the whole thing, to be able to reload next time you wanted to be in that specific environment defined by that directory. So, very similar to how things are done now in most respects, except the changes are made to the running Python object system, not the frozen textual representation of a pointing time of it. Naturally, you could still make changes by hand to the *.py files when the system was stopped, but if the GUI system was good enough, eventually few people might want to work that way for most things. It is also risky in another way, because loading a Python program could do anything to you system (unless we have Python VMs with Java like security limits on writing to files or sockets, where the VM enforces the restrictions internally from security flags). But then again, a Squeak image could do anything to your system when you load it in too. That security issue just needs to be dealt with at the VM level, or at the OS level, or through a system of trusted sites and so on (the "we're all consenting adults Python philosophy", etc.). So I think it could be managed in practice with risk equivalent to what we have now. --Paul Fernhout From chuck at freshsources.com Fri May 5 20:14:42 2006 From: chuck at freshsources.com (Chuck Allison) Date: Fri, 5 May 2006 12:14:42 -0600 Subject: [Edu-sig] Petty Issue Message-ID: <599704612.20060505121442@freshsources.com> Hello edu-sig, I'm really sorry to waste your time, but this is the only place I know to go to get a quick answer. I have mentioned here before that I am teaching intermediate Python at Symantec in June. Since they merged with another company last year, they have some new red tape that disallows one-person companies like myself to do business with them (it seems I don't have enough liability insurance - true - I have none!). To get around the system, I have to, among other things, "sell" them a Python book with a CD in it. (Don't ask me why - this is bean counting mentality at its best). Anyway, I can't find a worthy book with a CD. Most are out of date or too simple. (I wish Martelli's books had CDs!) Even John Zelle's excellent book, with has an accompanying CD, is too basic for our needs (it's an ideal CS1 book, of course). So: do you know of a book with a CD that is intermediate, or... do you know of a stand-alone CD product that covers some meaty Python? Thanks, and again, sorry to interrupt more profitable discussion. -- Best regards, -- Chuck Allison From ianb at colorstudy.com Fri May 5 21:18:12 2006 From: ianb at colorstudy.com (Ian Bicking) Date: Fri, 05 May 2006 14:18:12 -0500 Subject: [Edu-sig] PySqueak: "Self" as the source of many ideas in Squeak In-Reply-To: <445B8AF6.7050200@kurtz-fernhout.com> References: <445B02D3.7060504@kurtz-fernhout.com> <445B7BB7.70609@colorstudy.com> <445B8AF6.7050200@kurtz-fernhout.com> Message-ID: <445BA4F4.9020102@colorstudy.com> Paul D. Fernhout wrote: > Ian Bicking wrote: > >>Paul D. Fernhout wrote: >>This is a little of what I intend with HTConsole; the objects are >>(vaguely) live, and potentially shared. Though I've only implemented >>useful liveness for functions so far. It's at conflict with the idea of >>source code, and live objects really require an image, and I've never >>liked images. So I'm not sure if it's a useful path. > > > Ian- > > Thank you for your detailed reply and I promise more thought on it, but on > this one issue, to respond immediately, consider my earlier comments on > images and the muse as to a potential "Pythonic" resolution. Basically, it > is to think of the Python *image* as being defined by a Python *program* > that builds an object world and is stored in a textual *.py file, and just > looks and acts like regular Python source code -- ideally with comments > preserved too. So, no pickled objects, not binary image files, just Python > source code as readable text that rebuilds hierarchies and meshworks of > objects. That's very hard to implement... For instance, imagine the user does this: x = [1, 2] Then they get a handle on that [1, 2] list (we'll call it OB1) and do "OB1[0] = 5". How do we represent that as source? Because they are acting on actual objects, not bindings, and OB1 doesn't have any name, nor will it exist at the same address in a second run of the program. In order to turn this into source, you'd have to keep track of how you can repeatably get to OB1 (I guess you'd see that it was named "x" through source introspection?), and then translate operations on that object into source that does operations on the path to that object. I think doing this generally becomes infeasible, though you can get close through successively more bizarre source code generation, until you end up with something that looks like a Python-source version of pickle, and even that won't work very well. This is all not to say that modifying Python source in a manner different than ASCII is infeasible. Only that "source" and "runtime" have to be kept separate to keep this process sane. Images -- which mingle the two -- have never felt sane to me; clever, but not manageable. Unfortunately we do not have very good abstractions in Python related to source, so they have to be invented from scratch. The AST might help, but higher-level abstractions are also called for. For instance, you might define a color interactively in some fashion, and the color gets serialized to: import color color.Color(r, b, c) That color object might be immutable (probably should be), but the *source* isn't immutable, and the source means something. How can we tell what it means? I can imagine a bit of interaction between the source and the runtime to do this. For instance, we might see that "color" is bound to a specific module, and "color.Color" to a specific object. We'll disallow certain tricks, like binding "color" dynamically, monkeypatching something into "color.Color", etc. Ultimately figuring out exactly what color.Color is isn't *easy*, but at least it is feasible. Using existing introspection we can figure out some parts, some of the sorts of things that IDEs with auto-completion figure out. They can figure out what the arguments to Color() are and the docstring. But, you can also imagine adding an editor or other things to that object; a richer form of __repr__, or a richer editable form than the ASCII source. Maybe there would be a flag on Color that says it can be called without side effect (meaning we can speculatively call it when inspecting source); and then the resulting object might have something that says it can be displayed in a certain way (with its real color), and has certain slots you can edit and then turn into a new Color invocation. This is where the 'make' syntax starts to come into play again, or more generally where declarative source comes into play. Take a typical non-declarative module, like optparse: parser = OptionParser() parser.add_option('-v', '--verbose', action='store_true', dest='verbose', help='Be verbose') There's nothing there that looks like a literal; the first call to OptionParser isn't very interesting, all the structure is in later parts. This on the other hand: make OptionParser parser: make Option verbose: """Be verbose""" aliases = ['-v'] action = 'store_true' dest='verbose' that is really a much more fully-formed piece of source that can be understood as a complete piece; you could add methods to OptionParser and Option to make this usefully editable. (Or use generic functions to avoid having to modify those objects to give them rich source representations) Sometimes declarative structures are in conflict with runtime dynamicism, but I don't think they have to be. The declarative form doesn't make the .add_option() method obsolete; it just offers a static form for the most common case where you statically construct the options. There also might be a hint of static typing here -- an OptionParser source editor might suggest an option to add another Option, and so it will be bound to the Option class specifically; but it's just important to leave in the same generality in the source editor as the original source has. That is, OptionParser should defer to Option for the 'verbose' key that's already set. This is all harder than what HTConsole is doing currently, mostly because Python source introspection is much poorer than Python object introspection. > It is also risky in another way, because loading a Python program could do > anything to you system (unless we have Python VMs with Java like security > limits on writing to files or sockets, where the VM enforces the > restrictions internally from security flags). Loading a Python program can already do anything, if you put the commands at the top-level (not in a function). So Python source really is focused on constructing objects -- even functions and classes are *built* by the source, not declared by it, and so circular imports and circular class references can be challenging as a result. -- Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org From kirby.urner at gmail.com Fri May 5 22:08:47 2006 From: kirby.urner at gmail.com (kirby urner) Date: Fri, 5 May 2006 13:08:47 -0700 Subject: [Edu-sig] PySqueak: more on the cultural divide among paradigms In-Reply-To: <445B8491.9070802@kurtz-fernhout.com> References: <445B8491.9070802@kurtz-fernhout.com> Message-ID: On 5/5/06, Paul D. Fernhout wrote: > compromises with. Will PySqueak be a compromise or an innovation (or > both)? It remains to be seen. > > Trying to keep this short, but failing. :-) > > --Paul Fernhout I think we may be on different planets but I'm not sure. :-D As I understand it, PySqueak is not about changing existing Python syntax. Python syntax is controlled by Guido working with pydev people, and is moving towards Python 3000, so-called. The changes are incremental and have nothing much to do with the PySqueak effort. The PySqueak effort (badly named?) is more like the VPython effort. Its aim is to give us a sophisticated back end graphics engine to dink around with. Given this engine, Python developers might write apps friendlier to young children, using animation and almost-no-typing-needed interfaces. We could compete with the newer Logos, which leave the older ones in the dust, visually speaking. The very same engine would have lots of applications in an adult context as well. This is NOT about Python changing significantly as a language, moving to some new paradigm or yadda yadda. In my view, Python is a mature language undergoing consolidation, is not on the brink of some major overhaul. True, it's being reimplemented in C# for some platforms, as it was in Java (with Jim's leadership in both cases). The new graphics engine I envision might well be an outgrowth of that Mono/.NET effort. Only time will tell. In the meantime, we already have working, Ubuntu-compatible versions of Logo, Squeak and Python. My info is the Shuttleworth Foundation is in no way holding its breath waiting for these newer tools to come over the horizon, exciting though these may be. In terms of going ahead with implementation, we already have sufficient toyz. Curriculum writing is proceeding apace on that basis. Kirby From pdfernhout at kurtz-fernhout.com Fri May 5 22:15:59 2006 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Fri, 05 May 2006 16:15:59 -0400 Subject: [Edu-sig] PySqueak: "Self" as the source of many ideas in Squeak In-Reply-To: <445BA4F4.9020102@colorstudy.com> References: <445B02D3.7060504@kurtz-fernhout.com> <445B7BB7.70609@colorstudy.com> <445B8AF6.7050200@kurtz-fernhout.com> <445BA4F4.9020102@colorstudy.com> Message-ID: <445BB27F.9000100@kurtz-fernhout.com> Ian Bicking wrote: > That's very hard to implement... Probably true, at leas to do it in a human readable way. > For instance, imagine the user does this: > > x = [1, 2] > > Then they get a handle on that [1, 2] list (we'll call it OB1) and do > "OB1[0] = 5". How do we represent that as source? Because they are > acting on actual objects, not bindings, and OB1 doesn't have any name, > nor will it exist at the same address in a second run of the program. > > In order to turn this into source, you'd have to keep track of how you > can repeatably get to OB1 (I guess you'd see that it was named "x" > through source introspection?), and then translate operations on that > object into source that does operations on the path to that object. > > I think doing this generally becomes infeasible, though you can get > close through successively more bizarre source code generation, until > you end up with something that looks like a Python-source version of > pickle, and even that won't work very well. Just as reference to Squeak Smalltalk, it has a "changes" file that records each top level Transcript type interaction (equivalent to a Python shell in many ways) so that these can be replayed if you need to rebuilt an image from the last version you saved if there was a crash. That's not what I am proposing here. But to address your specif example, maybe it does point to a paradigm shift. Is this what you would do in an interactive session for your example? >>> x = [1, 2] >>> OB1 = x >>> OB1[0] = 5 >>> del OB1 >>> x [5, 2] >>> OB1 Traceback (most recent call last): File "", line 1, in ? NameError: name 'OB1' is not defined But, your "program" in terms of an image at that point no longer needs to assign "x = [1, 2]". What it needs to do, to get back to where it is, is assign "x = [5, 2]" if I understand your example correctly? Basically, there is a bound variable in some scope, and a value it is. As long as objects are reachable, we can write them out starting from roots of the system (class path, the stack, modules and globals, and so on). Anything we cant; reach should have been garbage collected anyway (though might not have with CPython's reference counting system). So, we recreate the binding and the object in as simple a way as possible, to make the objects that are part of the accessible system. (Might make sense to combine this work with a true generational mark-and-sweep multiple-spaces tenuring etc. garbage collection system for Python? :-) Maybe I don't understand the example? As I see it right now, while it might be interesting to have a change log about how objects got to be how they are now, what counts when saving an image to a Python *.py file for future reload would be just their current structure and the name bindings. As a note, remember that if there was a line of program code somewhere to create an object using a class, using "x = [1, 2" that line would be stored and regenerated as part of the class being stored. The fact that creating a new object using an "test = Spam()" would assign test.x = 1 is independent of the fact that in recreating test, we might do: test = object() test.__class__ = Spam # can this work? fails with a TypeError test.x = 5 or, with some sort of optimizing storage system geared to writing human-equivalent code rather than doing things one piece at a time: test = Spam() text.x = 5 Again, though maybe I am missing something obvious here? Now, there may be a lot of things to improve this. I like your "make" idea in that regard, and perhaps other ideas could help with that as well. You are absolutely right in Python syntax defining how to create a set of objects being more than declaring a specific structure. Forth has some of the same aspects (only worse!). It is a big headache in many ways to analyze Forth (as opposed to Smalltalk or Java or plain C) but Python now has the advantage that this approach of using a Python program to save the state of a sea of objects is more feasible. Obviously somewhere you are going to have some code with a lot of declaration of temporary variables and deleting them for complex manipulation on structures. Perhaps this could require sort of engine to optimize how to do that in a human readable way, sort of like an optimizing compiler? A big task, but potentially doable for people who like that sort of thing. --Paul Fernhout From ianb at colorstudy.com Fri May 5 23:07:50 2006 From: ianb at colorstudy.com (Ian Bicking) Date: Fri, 05 May 2006 16:07:50 -0500 Subject: [Edu-sig] PySqueak: "Self" as the source of many ideas in Squeak In-Reply-To: <445BB27F.9000100@kurtz-fernhout.com> References: <445B02D3.7060504@kurtz-fernhout.com> <445B7BB7.70609@colorstudy.com> <445B8AF6.7050200@kurtz-fernhout.com> <445BA4F4.9020102@colorstudy.com> <445BB27F.9000100@kurtz-fernhout.com> Message-ID: <445BBEA6.1080900@colorstudy.com> Paul D. Fernhout wrote: > Ian Bicking wrote: > >>That's very hard to implement... > > > Probably true, at leas to do it in a human readable way. > > >>For instance, imagine the user does this: >> >> x = [1, 2] >> >>Then they get a handle on that [1, 2] list (we'll call it OB1) and do >>"OB1[0] = 5". How do we represent that as source? Because they are >>acting on actual objects, not bindings, and OB1 doesn't have any name, >>nor will it exist at the same address in a second run of the program. >> >>In order to turn this into source, you'd have to keep track of how you >>can repeatably get to OB1 (I guess you'd see that it was named "x" >>through source introspection?), and then translate operations on that >>object into source that does operations on the path to that object. >> >>I think doing this generally becomes infeasible, though you can get >>close through successively more bizarre source code generation, until >>you end up with something that looks like a Python-source version of >>pickle, and even that won't work very well. > > > Just as reference to Squeak Smalltalk, it has a "changes" file that > records each top level Transcript type interaction (equivalent to a Python > shell in many ways) so that these can be replayed if you need to rebuilt > an image from the last version you saved if there was a crash. That's not > what I am proposing here. > > But to address your specif example, maybe it does point to a paradigm > shift. Is this what you would do in an interactive session for your example? > >>> x = [1, 2] > >>> OB1 = x > >>> OB1[0] = 5 > >>> del OB1 > >>> x > [5, 2] > >>> OB1 > Traceback (most recent call last): > File "", line 1, in ? > NameError: name 'OB1' is not defined Interactive sessions are source. The OB1 I referred to is the actual object in memory, which has no real name, though it can be referenced directly in memory. Maybe a better example is something in HTConsole right now. Any function you can get your hands on in HTConsole is editable, in-place. So you can do: >>> import random >>> random.choice And you'll get a form that shows the source to that function, and lets you edit it. That works fine in-memory. But saving that is hard. There's actually lots of ways to get access to a function. When you get random.choice, you are actually getting access to a method of a singleton stored in the random module. When you edit that, you are editing the method. How do you represent that edit as source? Do you see that the function is available as random.choice.im_func, or random.Random.choice? Or a property, which might be available as SomeClass.some_property.fget. There's lots of paths to functions, and the function alone doesn't necessary know how to get to it. And functions are relatively easy; other objects can be much harder... >>> items = range(5) The contents of items cannot be edited in place, because they are recreated dynamically. They can only be modified by later commands. Keeping a log of commands is possible. But you aren't editing live objects anymore, except perhaps an illusion of that. Instead you are generating saveable commands from a specific location, which are immediately executed to give you feedback but also saved so they can be replayed in the future. As I've been thinking about this, I think command generation is pretty much like direct source modification, but direct source modification also leads to nice source. So that's why I'm thinking that live objects isn't a good metaphor, after going down that path some. -- Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org From ianb at colorstudy.com Fri May 5 23:15:19 2006 From: ianb at colorstudy.com (Ian Bicking) Date: Fri, 05 May 2006 16:15:19 -0500 Subject: [Edu-sig] PySqueak: more on the cultural divide among paradigms In-Reply-To: References: <445B8491.9070802@kurtz-fernhout.com> Message-ID: <445BC067.9060104@colorstudy.com> kirby urner wrote: > The PySqueak effort (badly named?) is more like the VPython effort. > Its aim is to give us a sophisticated back end graphics engine to dink > around with. I thought there was some idea about an IDE, ala Squeak; or at least I assume this is what Paul was thinking about. Is any IDE or interactive environment planned, or just a graphical environment? If it's just a graphical environment, then why not VPython? Or Soya3D? (Incidentally there's several Summer of Code proposals for Soya3D). Or PyGame, or some library sitting on top of PyGame. Or PythonCard. Or, heck, HTML. To me, the IDE experience of Squeak or a Logo (not including UCB Logo, of course) is far more interesting and unattained by Python than any particular graphic capability. Which is where the IDEish ideas come about, which seems like what was motivating Paul. -- Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org From kirby.urner at gmail.com Fri May 5 23:56:05 2006 From: kirby.urner at gmail.com (kirby urner) Date: Fri, 5 May 2006 14:56:05 -0700 Subject: [Edu-sig] PySqueak: more on the cultural divide among paradigms In-Reply-To: <445BC067.9060104@colorstudy.com> References: <445B8491.9070802@kurtz-fernhout.com> <445BC067.9060104@colorstudy.com> Message-ID: On 5/5/06, Ian Bicking wrote: > kirby urner wrote: > > The PySqueak effort (badly named?) is more like the VPython effort. > > Its aim is to give us a sophisticated back end graphics engine to dink > > around with. > > I thought there was some idea about an IDE, ala Squeak; or at least I > assume this is what Paul was thinking about. Is any IDE or interactive > environment planned, or just a graphical environment? I was thinking the low level API to the graphics engine would then allow developers to build their various IDEs, much as GTK does, except the widgets would be more 3D. The source code for these IDEs could be Python, but if multiple language bindings are supported, could just as well be some other language. In my view, a generic graphics engine that doesn't hard-code or hard-specify a particular IDE would give us more freedoms. But there'd have to be an event model and so on, so a lot of thinking about how to support graphical IDEs would be a part of the engine. Kirby From kirby.urner at gmail.com Sat May 6 00:07:57 2006 From: kirby.urner at gmail.com (kirby urner) Date: Fri, 5 May 2006 15:07:57 -0700 Subject: [Edu-sig] Petty Issue In-Reply-To: <599704612.20060505121442@freshsources.com> References: <599704612.20060505121442@freshsources.com> Message-ID: > I have mentioned here before that I am teaching intermediate Python > at Symantec in June. Since they merged with another company last > year, they have some new red tape that disallows one-person > companies like myself to do business with them (it seems I don't > have enough liability insurance - true - I have none!). To get > around the system, I have to, among other things, "sell" them a > Python book with a CD in it. (Don't ask me why - this is bean > counting mentality at its best). Wow, that sounds restrictive! How about this one: http://www.amazon.com/gp/product/0130923613/102-8834637-6402554?v=glance&n=283155 Not as good as John Zelle's, but covers all manner of topics, so as a jumping off point, it could take you just about anywhere, provided you're allowed to supplement with your own material. Kirby From winstonw at stratolab.com Sat May 6 00:49:58 2006 From: winstonw at stratolab.com (Winston Wolff) Date: Fri, 5 May 2006 18:49:58 -0400 Subject: [Edu-sig] MakeBot for Windows Message-ID: <67314DFF-7B29-48A2-ABDA-7DB88AF413A4@stratolab.com> I have just released a Windows version of MakeBot, an IDE intended for students learning Python. It includes a very nice graphics/video game package based on PyGame. You can read all about it here: http://stratolab.com/misc/makebot/ -Winston ______________________________________________________ winston wolff - (646) 827-2242 - http://www.stratolab.com learning by creating - video game courses for kids in new york From delza at livingcode.org Sat May 6 00:54:59 2006 From: delza at livingcode.org (Dethe Elza) Date: Fri, 5 May 2006 15:54:59 -0700 Subject: [Edu-sig] PySqueak: more on the cultural divide among paradigms In-Reply-To: References: <445B8491.9070802@kurtz-fernhout.com> Message-ID: <24d517dd0605051554j11622b10wcdfd1e92b4bbacb5@mail.gmail.com> On 5/5/06, kirby urner wrote: > On 5/5/06, Paul D. Fernhout wrote: > > > compromises with. Will PySqueak be a compromise or an innovation (or > > both)? It remains to be seen. > > > > Trying to keep this short, but failing. :-) > > > > --Paul Fernhout > > I think we may be on different planets but I'm not sure. :-D > > As I understand it, PySqueak is not about changing existing Python > syntax. Python syntax is controlled by Guido working with pydev > people, and is moving towards Python 3000, so-called. The changes are > incremental and have nothing much to do with the PySqueak effort. > > The PySqueak effort (badly named?) is more like the VPython effort. > Its aim is to give us a sophisticated back end graphics engine to dink > around with. Would a VPython implemented on top of PyOpenGL be useful? Right now VPython lives in its own world and doesn't play nice with native windows, or PyGame, or OpenGL, or X3D, or OS X, or... The argument for making writing it the way they have it to get the performance necessary for physics demos. Meanwhile, Python has gotten faster, machines have gotten *much* faster, and PyOpenGL is getting faster by moving to a ctypes-based implementation. Would a pythonic 3D API, a la VPython, that plays well with others be a valuable component for the Squeakification of Python? Or are we talking apples and oranges (pythons and rubies)? > Given this engine, Python developers might write apps friendlier to > young children, using animation and almost-no-typing-needed > interfaces. We could compete with the newer Logos, which leave the > older ones in the dust, visually speaking. How intricate an engine are you thinking? VPython is still fairly primitive in its primitives, but a more open version might be extensible to read data from X3D, 2nd Life, SketchUp, AvMotion (character animation), etc. > The very same engine would have lots of applications in an adult > context as well. I know I'd love to have a 3D environment that was both easy to use, and extensible. > This is NOT about Python changing significantly as a language, moving > to some new paradigm or yadda yadda. > > In my view, Python is a mature language undergoing consolidation, is > not on the brink of some major overhaul. > > True, it's being reimplemented in C# for some platforms, as it was in > Java (with Jim's leadership in both cases). > > The new graphics engine I envision might well be an outgrowth of that > Mono/.NET effort. Only time will tell. > > In the meantime, we already have working, Ubuntu-compatible versions > of Logo, Squeak and Python. > > My info is the Shuttleworth Foundation is in no way holding its breath > waiting for these newer tools to come over the horizon, exciting > though these may be. > > In terms of going ahead with implementation, we already have > sufficient toyz. Curriculum writing is proceeding apace on that > basis. But Guido has committed that a Squeak-like GUI platform would be welcome. So we are talking about extending the libraries to be more encompassing. I agree about not extending the syntax (any more than is already happening for Python 3000). --Dethe > > Kirby From kirby.urner at gmail.com Sat May 6 05:47:29 2006 From: kirby.urner at gmail.com (kirby urner) Date: Fri, 5 May 2006 20:47:29 -0700 Subject: [Edu-sig] PySqueak: more on the cultural divide among paradigms In-Reply-To: <24d517dd0605051554j11622b10wcdfd1e92b4bbacb5@mail.gmail.com> References: <445B8491.9070802@kurtz-fernhout.com> <24d517dd0605051554j11622b10wcdfd1e92b4bbacb5@mail.gmail.com> Message-ID: On 5/5/06, Dethe Elza wrote: > Would a VPython implemented on top of PyOpenGL be useful? Right now > VPython lives in its own world and doesn't play nice with native > windows, or PyGame, or OpenGL, or X3D, or OS X, or... The argument > for making writing it the way they have it to get the performance > necessary for physics demos. Meanwhile, Python has gotten faster, > machines have gotten *much* faster, and PyOpenGL is getting faster by > moving to a ctypes-based implementation. I think VPython grooves on having a very minimalist API. The documentation is only a couple of pages, if that. It's really designed to be friendly to like a CS0 new user, and does a pretty good job of that (I've certainly appreciated having it installed at PSU, where I teach pythonic mathematics). > Would a pythonic 3D API, a la VPython, that plays well with others be > a valuable component for the Squeakification of Python? Or are we > talking apples and oranges (pythons and rubies)? > Looking at Croquet and the latest Logo, I'm seeing 3D as the way we're going, which disqualifies PyGame except as it's a window to OpenGL. My understanding of OpenGL is it could certainly do the job, but we might want to develop a new API for it, more suitable for coding event-driven IDEs. But maybe that's already part of the spec. I know Blender codes all its control widgets inside the OpenGL context. Pretty strange looking, but so is Squeak. > > Given this engine, Python developers might write apps friendlier to > > young children, using animation and almost-no-typing-needed > > interfaces. We could compete with the newer Logos, which leave the > > older ones in the dust, visually speaking. > > How intricate an engine are you thinking? VPython is still fairly > primitive in its primitives, but a more open version might be > extensible to read data from X3D, 2nd Life, SketchUp, AvMotion > (character animation), etc. > I'm thinking like a serious game engine, like lives behind Quake and Half-Life 2 and like that. Quaternions anyone? > > The very same engine would have lots of applications in an adult > > context as well. > > I know I'd love to have a 3D environment that was both easy to use, > and extensible. > Me too. > > This is NOT about Python changing significantly as a language, moving > > to some new paradigm or yadda yadda. > > > > In my view, Python is a mature language undergoing consolidation, is > > not on the brink of some major overhaul. > > > > True, it's being reimplemented in C# for some platforms, as it was in > > Java (with Jim's leadership in both cases). > > > > The new graphics engine I envision might well be an outgrowth of that > > Mono/.NET effort. Only time will tell. > > > > In the meantime, we already have working, Ubuntu-compatible versions > > of Logo, Squeak and Python. > > > > My info is the Shuttleworth Foundation is in no way holding its breath > > waiting for these newer tools to come over the horizon, exciting > > though these may be. > > > > In terms of going ahead with implementation, we already have > > sufficient toyz. Curriculum writing is proceeding apace on that > > basis. > > But Guido has committed that a Squeak-like GUI platform would be > welcome. So we are talking about extending the libraries to be more > encompassing. I agree about not extending the syntax (any more than > is already happening for Python 3000). > > --Dethe I was at the meeting with Alan Kay from where he first sent out the call (not to this list). I think many elements of Squeak intrigue him. But exactly what "Squeak-like GUI" means is not yet well defined. For example Squeak isn't particularly 3D (unlike Croquet), yet I think that's where we need to be heading with this engine we're talking about. Kirby From pdfernhout at kurtz-fernhout.com Sat May 6 07:44:15 2006 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Sat, 06 May 2006 01:44:15 -0400 Subject: [Edu-sig] PySqueak: more on the cultural divide among paradigms In-Reply-To: References: <445B8491.9070802@kurtz-fernhout.com> Message-ID: <445C37AF.4050007@kurtz-fernhout.com> Kirby- Clearly we're both likely on the same planet, but just as clearly our priorities are different (e.g. I may want to permanently move off of it more than you :-). http://www.kurtz-fernhout.com/oscomak/SSI_Fernhout2001_web.html http://www.kurtz-fernhout.com/oscomak/AchievingAStarTrekSociety.html And there is nothing wrong with that; there is a lot of value in diversity in a community. One of the marvels of free and open source software communities is that people work on stuff they like to work on, and others get to do the same. When those interests overlap, then great. When they don't, then also great, as the community is still trying a lot of different things, and the evolutionary results are visible to the community, and can be built upon as desired. It is frustrating to see all the duplicated and aborted efforts, but it is also exciting to see an unexpected effort (like Python once was) catch fire to its fuse and shoot up to the stars. Sometimes that work is coding; sometimes it is designing; sometimes it is just talking about priorities and values and history. Personally, I think the world has too much code already, and my mission is, in part, to get rid of much of it. :-) I read once you can measure the power of a new idea by how many bookshelves worth of books in the library it obsoletes; I imagine the same applies for code. Again, from: http://www.sysprog.net/quotprog.html "Fifty years into the First Computing Era some of us in the computing arena have come to realize we've made a false start, and for us to finally be able to produce lasting, correct, beautiful, usable, scalable, enjoyable software that stands the tests of time and moral human endeavor, we need to start over. (Richard P Gabriel)" Still, if I can leverage Python and the Python community to that end, then so much the better. Probably that will fail, but possibly worth the try I feel. Anyway, I feel there is room enough for your vision of a "PySqueak" and also for my vision of "PySqueak". And may the better version win, or split, or gain adherents, or whatever -- assuming "better" even makes sense to use when people have so many differing priorities and what is good for one purpose may be not so good for another. :-) To recap, as I see it, this PySqueak effort gained some traction when you and Guido cam back from the summit, having seen Alan Kay's presentation of Squeak and Croquet. I'm sure it was dazzling, as Alan Kay is a captivating speaker and Squeak and Croquet have a lot of really great features.(*) So, with the two of you, who provide a lot of the leadership on edusig, suitably impressed with the potential for dynamic interactive environments based on a prototype paradigm for use in education (as well as general programming), some discussion starts here. And I butt in, and say, hey, that's what I was talking about six years ago. :-) And so some further discussion ensues (complete with educational paradigm distractions :-). Now by all means, I think a popular and well supported open source Croquet-like 3D environment on Python would be a good thing. I believe that for the same reasons I think it was neat in LearningWorks, the original Python Alice (which I played with many years ago): http://www.cs.cmu.edu/~stage3/publications/95/journals/IEEEcomputer/CGandA/paper.html VPython, and other systems as well. And even in ActiveWorlds, which bills themselves as: "Home of the 3D Chat, Virtual Reality Building Platform". http://www.activeworlds.com/ and see "Python for ActiveWorlds"! http://www.crepuscule.com/aw/ But I could also add in many MUDs and MOOs and MMORPGs of various types (textual and graphical of various sorts, including even franchised ones). These things are all really neat. And I can see how the could be motivating to some people to do some interesting learning. I'd love to have a good one to work with in Python to simulate life in a space habitat network, for example. And if Shuttleworth wants to help fund such a thing, I'm not above taking some of his money as a subsidy :-) if it otherwise links in with also advancing some of my own constructivist agenda items (though they clash somewhat with his school-based approach). Clearly, and I think correctly for his plans as he sees them now, his strategy, reflecting your emphasis that Python-as-it-is can do a lot of neat educational things, is a very good one. I might quibble with the school orientation, and while wishing him success expect him to need to revise those plans someday for reasons previously outlined, but it is his money. Certainly I come with my own set of baggage (re unschooling and free schooling) so I can acknowledge there are probably many better or more compatible candidates than I, just on the basis of that, to work closely with a Shuttleworth activity targeted at schools (and, of course, there are much better Python programmers out there than I too). And no bad feelings should someone else get paid to do that work. Good for him/her. Frankly, Mark would probably be better off spending his funds on any new development in South Africa anyway (where his money is based), where he could hire more developers for the cost of less US ones, plus these developers would become greater assets to the SA economy (though he made it clear in the email Guido forwarded that he had little interest in spearheading a major development effort of any sort, anyway). So, I think we can discount the Shuttleworth Foundation as the major player in PySqueak. Not inconsequential, and not unimportant, and of course not uninstrumental (such as by bringing Guido and you and Alan together), but just not dominant (at least, right now). As you say, they are happy with what they have right now, and see the major need just making curriculum guides using existing tools. Good luck to them with that, and I hope it works out well despite my reservations, etc. And I'm sure that may be their (initial) attitude towards a PySqueak. But, even if that foundation fully underwrote the full-time cost of a developer or project manager working on a semi-volunteer pay-scale (which does not even seem to be what they proposed) the effort will only succeed with buy-in from members of the Python community (and possibly members of the Squeak community). So the question then becomes, what makes sense to various people in the community willing to volunteer time to do some coding, contribute ideas, write documentation, draw icons, submit bug reports, testing, provide advice, and so on towards PySqueak? Who are these people? Well, right now, you are still stuck with just me. :-) http://sourceforge.net/projects/patapata [no code there yet] And hopefully someday, some others. And, we all might never agree, but maybe some useful things will hopefully come out of that anyway. :-) Or, more seriously, given that those other 3D Python technologies exist and have not set the world on fire, and Jython exists and has not set the educational applet world on fire, and ActiveWorlds and LearningWorks and so on exist and have not set the world on fire (in such a way you personally are willing to dump Python just to have 3D worlds), and given that Squeak and Croquet exist and you would rather reinvent them in Python than retool in Squeak Smalltalk (a few weeks for you, I'd say, tops, doing a medium sized app, to be feeling comfortable), given all that, I question that another stab at 3D worlds on Python will set the educational world on fire (especially as you can apparently even script ActiveWorlds with Python already, though obviously that is not the same as Croquet). All that is very neat, yes. Fun to do, yes. Worth taking money for to put food on the table and honorably do what you said you'd do, yes. Useful as a vehicle to build other things on top of and a way to learn such a thing by working on it, yes. But, is reinventing Squeak-and-Croquet-as-it-is-in-Python something to knock yourself out for if you think some other more basic issues are more important, then, no. And I fall into the "no" camp in that sense. Porting Squeak and Croquet (or a 3D engine) to Python, when I could just use Squeak and Croquet and OpenGL, seems like not the most fun or productive thing I personally could do with years of my time (others might like it more, and find more value in it for them, of course). But, approaching it as I outlined, trying to take the best of the *ideas* from Squeak and Croquet and Self and constructivism and trying to bring them to a Python platform in a Pythonic and hopefully better way (and with special emphasis on unschooling and informal science education), or in essence, to "burn the disk packs" and try to out-Squeak Squeak, now that begins to sound worth trying (for me). And if approached respectfully, I think Alan Kay's group as well as the Self group could be some part of that. I'm sure by now after about a decade of Squeaking that Alan's group knows (at least intuitively) more about the limitations and disappointments and frustrations of what they were trying to do with Squeak and Croquet than anyone (whether they will list these and admit them, given a need for hype for funding, is a different story). Something I myself wrote on that topic in 2000 to the Squeak list: "Belling the cat of complexity" http://lists.squeakfoundation.org/pipermail/squeak-dev/2000-June/001371.html And, IMHO, for me, it is still worth trying to make a better-than-Squeak constructivist system with Python even if it is harder and more likely to fail than porting Squeak-as-is to Python, because it is IMHO more likely to succeed in the world if it really works out, more than a "me too" Squeak clone in Python, which without a community that likes it and uses it, will just wither. And Squeak already has the community (though Art has some strong words written to this list on the compromises involved to get there, which are starting to reshape my views on this). Getting a community is much harder (for me or any programmer) than writing code. Which actually is an argument for me to, say, jump ship to, say, Self or Squeak as it is, but let's ignore that, based in part on the fact that for me, I see Python skills a having a significant potential current and future commercial value, as Python is up and coming, whereas Smalltalk, sadly, is on the ropes :-( (Ah, but the good old days with Smalltalk were very good indeed :-). Still, part of my writing here is to think in public about whether any aspect of this project makes sense for me (as opposed to, say, just switching to Self). I might still decide it does not make sense for various reasons, not the least of which might be if the edusig community and its culture really don't want something like Self built on Python. [I am at least heartened by a few people's comments here, Ian's especially.] Of the development plan I outlined for a PySqueak approach, the last part, the focus on 3D worlds, was of much less interest to me than the other parts. To me, what makes Smalltalk great is the ability to debug and inspect and reprogram anything you see, and the beauty of Squeak, in part as a reflection of "Self", is in the power of constructivist ideas relating to the GUI, although going beyond that. I don't want to ignore the other neat technological ideas in Squeak ranging from direct pointer object IDs to the underlying network OS ideas, but they come second in my opinion to what makes Squeak attractive. Without the programmable interactivity, you are left with a scriptable ActiveWorlds, which we have now!. And also, for me, especially having read things here on edusig about the value of interactivity on the command line, about the value of learning different ways of doing things, and knowing about how "what you see is what you get" can be superseded by "what you see is really neat and useful", and even some off-list discussions with Art (Guido's comment comparing us prodded me to look him up :-), these all make me realize that while there is value in providing people a concrete 3D interface, I also think there is greater value in giving people a range of tools and representations, perhaps implemented by a different variety of systems. And, the 3D worlds can actually take away from a focus on the basics of programming. To fight that all by pushing "one 3D VM to bind them all" :-) in a "Snow Crash" sort of way http://en.wikipedia.org/wiki/Snow_Crash is just not going to work (at least anytime soon), and is definitely not the Python (glue) way. To paraphrase, the great thing about standard VMs is that there are so many versions of them to chose from. On a practical basis I agree with you that expecting to make progress changing the Python syntax in any significant way is unlikely to go anywhere. But I also think it is feasible to consider minor changes to Python to support better introspection or object building, although, frankly, I think a lot could be done with Python just as it is right now. Specifically, as I and others stated, one can extend the libraries, or write new libraries, or create a prototype base class, or use Python in new and unexpected ways (like writing image files as Python source), or one can push for new networking paradigms and standards (like Python apps having a low-level networked programming interface if started with a debugging thread). So, there is a lot of mileage one can get from those directions without touching syntax, and I think they remain to be explored in depth. But, without discussions on these points (even if sometimes just soliloquies), I don't think some of those ideas would emerge. And they would not have a chance to be archived for future reflection or Google searches, or commented on as stupid or redundant or insightful or whatever. I come to Python from Squeak and other Smalltalks (though I first learned OO with ZetaLisp on a Symbolics). And I find much to be missed from those days in Smalltalk, ranging from not needing superfluous periods between accessors [e.g. "f v append(poly verts[i])" instead of "f.v.append(poly.verts[i])" if Python dropped them] to simply always having a debugger I can code in at hand when an exception pops up anywhere. Python, its Occam-style indentational syntax (I learned Occam first), and above all its community, are so fantastic in so many ways that they make up for much of what is missing on a practical basis. But there still remain missing pieces. And when you see a presentation by someone like Alan Kay, he makes you very aware of them, either consciously or unconsciously. Still, Squeak misses things Python has too (like the "open source" license, and the stability, and the libraries, and the glue-like philosophy). So, I am coming from that perspective of getting those missing Smalltalk basics working first for Python (and ignoring historical syntax "bugs" like the superfluous period from C/Pascal syntax compatibility). Only then, using hopefully better tools for managing complexity, would I think more about crossing ActiveWorlds with OO scripting yet again or reinventing OpenGL to get a Python version of something like Croquet (should either of those really be needed, compared to working with existing Python projects). Frankly, if you just want Python Alice crossed with a MMORPG, then there are much easier ways to do it (and probably others potentially more interested in that, like the people who wrote Python/Alice or VPython or even one of the Python MUDs or MOOs). But if you want systems that make it easy for anyone, especially novices, to get involved with programming in Python (CP4E) then I think taking good ideas from Self and putting them in a Python context could be a big win, and is something I am interested in. Anyway, I think the "we" in your comment "we already have sufficient toyz" doesn't entirely speak for everyone. Clearly, I do not have "Self" in Python yet, which I want. (Or do I, so much is going on in Python?) Anyway, same planet, different outlooks. And that makes for an interesting (if sometimes stressful :-) world. --Paul Fernhout (*) The features in Squeak which are impressive are still mostly derivative in many ways, as I have previously posted on, although many of the derivations also trace back to Alan Kay and his group in the 1970s, so assigning such credit is a complex topic. kirby urner wrote: > As I understand it, PySqueak is not about changing existing Python > syntax. > [snip] > The PySqueak effort (badly named?) is more like the VPython effort. > Its aim is to give us a sophisticated back end graphics engine to dink > around with. > [snip] > This is NOT about Python changing significantly as a language, moving > to some new paradigm or yadda yadda. > > My info is the Shuttleworth Foundation is in no way holding its breath > waiting for these newer tools to come over the horizon, exciting > though these may be. > > In terms of going ahead with implementation, we already have > sufficient toyz. Curriculum writing is proceeding apace on that > basis. From pdfernhout at kurtz-fernhout.com Sat May 6 08:44:04 2006 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Sat, 06 May 2006 02:44:04 -0400 Subject: [Edu-sig] PySqueak: "Self" as the source of many ideas in Squeak In-Reply-To: <445B7BB7.70609@colorstudy.com> References: <445B02D3.7060504@kurtz-fernhout.com> <445B7BB7.70609@colorstudy.com> Message-ID: <445C45B4.9060503@kurtz-fernhout.com> Ian Bicking wrote: > Some things other people have done (like Logix: > http://livelogix.net/logix/) makes me think that this could be done in > CPython now, with just some fiddling in the compile process. I think > the Python object model (which can't easily be changed) is already > flexible enough for this. > > And ignoring some syntactic details you could do this in current CPython. Interesting concept, to put it mildly. And also interesting under "future work" they say: http://livelogix.net/logix/future-work.html "Although Python has provided a great launch pad for Logix, we may switch to another platform at some point. Efficiency and security are two areas that are somewhat lacking with a Python foundation. What are the alternatives? Maybe Mono, maybe Parrot, maybe C--, maybe LLVM..." I know that is one of the reasons I still think about doing something (at least proof of concept) in Jython -- because it can piggy back on the Java JVM security model, and I might also consider writing a low level routine for handling networked programming in Java (if speed was an issue, after doing it all first in Jython). [But, I've also been looking at working with the Idle codebase too, by building on its RPC functionality.] Still, the less I can mess with the syntax the better, I think. That's why I lean towards just having one "Prototype" class. >> I think that Ian's suggestion is the most sensible strategy for >> proceeding >> in that direction and continuing to maintain community interest in a >> PySqueak inclined towards Self-like prototypes and a related GUI for >> constructivist educational use (and other general use as well). >> And if metaclasses turn out to not be the best approach, >> still anything simple which preserves the Python syntax >> while giving the new features (say, having all prototypes inherit from >> a common class which overrides __getattr__ and __setattr__ to >> simply look into the instance to find data and behavior?) > > I think it could be easier than that. I think a lot of the more > declarative programming I do really has prototypes underneath it. > (Ironically in Javascript I never find a need for prototypes, except to > simulate classes.) Of course, you probably don't have a Self-like environment for Javascript. :-) Or is there one? I've never done much with JavaScript. I did once listed about 100 reasons to use VisualWorks Smalltalk over C+++ without having to talk specifically about object-oriented programming issues -- just focusing on the environment and the libraries and the VM and issues like garbage collection and integrated fine-grained version control. Anyway, I tried to follow your example, but I am still left confused as to how it is easier than creating GUI tools that manipulate all instances of just one Prototype class? Your example still seems focused on making classes. With one class, a few lines of code to search for values through parent slots and you're done? Essentially, for any prototype-ish work, one would just work with instances of this one class. Am I missing somethgin vital here? Are you thinking about one class per one prorotype object? Is that for performance reasons? Consider: >>> class Prototype: ... def __getattr__(self, name): ... print name ... >>> x = Prototype() >>> x.spam("hello") spam Traceback (most recent call last): File "", line 1, in ? TypeError: 'NoneType' object is not callable >>> Of course it fails trying to call the None returned by default in __getattr___ because the code just prints the field name, but you see I could just have that __getattr__ method look into a field of the object and return the function, or if it was not there, then start looking into parent slots and recursing until it found it or gave up with a call to a "does not understand" function (itself hookable). I do think there might be issues to resolve in how instances of this class interact with other python classes. But I am not sure how complex those issues are, since everything to Python still looks just like a typical python class. All calls work the same way? Or do they? The issues might have more to do with the GUI and it being able to handle dealing with instances of other classes, but that could be done in the usual way such as with inspectors and such that Idle defines. A bit klunky, but probably serviceable as a start? Anyway, something to think more on. A proof-of-concept Prototype class and a GUI to manipulate it should not be that hard. (Famous last words. :-) Designing programming systems is so easy when you stop caring about performance (at least in the short term). :-) But the advice I was given long ago is, slightly updated, is: by the time you get it debugged and anyone has noticed it, computers will be fast enough to run it. :-) Anyway, are there compelling reasons why creating one class per prototype is useful or better? Or maybe I am just missing something here. Perhaps it is confusing in that we are talking about two issues. One is saving the state of a running Python program with arbitrary classes and instances which you have modified while it runs, and the other is an application building process centered around prototypes with classes being more a legacy thing. > I'm not really sure how to fit HyperCard into this -- I don't have a > strong feel for what it really means. I suppose one aspect is that the > source code is not at the core; instead the card stack is (or whatever > content-centric metaphor you use), and code is attached there. Ad hoc > structured code doesn't work that well with a class... you get something > like: > > class Foo: > def bar(self)... > > foo = Foo() > > And the class/instantiation is just a kind of boilerplate. OTOH, > modules are another model; if each content-context (aka card) was a > module, you get some of the structure without the conceptual overhead of > the class. Yes, it would be that simple using classes I think. Or it could be done using prototypes: p = Prototype() p.border = "dotted" p.background_color = "red" p.foreground_color = Color.red # if allow mixing classes and prototypes p.parent = CARD_TEMPLATE_PREVIOUSLY_DEFINED But I kind of see HyperCard as more like just one set of widgets in a Morphic style interface. Have you had a chance to watch the Self video? Another source for it: http://www.smalltalk.org.br/movies/ If you haven't, I recommend it highly. --Paul Fernhout From pdfernhout at kurtz-fernhout.com Sat May 6 09:25:49 2006 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Sat, 06 May 2006 03:25:49 -0400 Subject: [Edu-sig] PySqueak: "Self" as the source of many ideas in Squeak In-Reply-To: <445BA4F4.9020102@colorstudy.com> References: <445B02D3.7060504@kurtz-fernhout.com> <445B7BB7.70609@colorstudy.com> <445B8AF6.7050200@kurtz-fernhout.com> <445BA4F4.9020102@colorstudy.com> Message-ID: <445C4F7D.70104@kurtz-fernhout.com> Ian Bicking wrote: > This is all not to say that modifying Python source in a manner > different than ASCII is infeasible. Only that "source" and "runtime" > have to be kept separate to keep this process sane. Images -- which > mingle the two -- have never felt sane to me; clever, but not > manageable. Well, perhaps sanity is overrated. :-) And Smalltalk has been managing this for thirty years. :-) But it is true, it requires a bunch of special purpose tools. Changeset browsers. A change log. External source code control. Image cloners. and so on. Probably a Python that stored a running image as Python program files might need some specialized tools too. And I will go further and agree that I find mixing running application state (like what windows are opened or what the stack looks like) with application data (your email, your accounts receivable) is pretty scary too. But again, one needs some sort of tools to help you with that, and there is no reason some things can't be in the image and other things not in it. In a Smalltalk system, generally there is at least a file with library source code and a file with user additions to that as a current change log. Although in the case of Squeak, it can decompile methods (if it saves comments) even if you don't have the source code. One of the people on the project (Alan Kay or Dan Ingalls?) quipped something to the effect that a Squeak image was really a source code compression algorithm with a development environment thrown in for free. But, a Smalltalk image is generally saved as binary objects. But now that disk is cheap and cpu cycles plentiful, storing an image as python program files seems OK to me resource-wise. > Unfortunately we do not have very good abstractions in > Python related to source, so they have to be invented from scratch. The > AST might help, but higher-level abstractions are also called for. For > instance, you might define a color interactively in some fashion, and > the color gets serialized to: > > import color > color.Color(r, b, c) > > That color object might be immutable (probably should be), but the > *source* isn't immutable, and the source means something. How can we > tell what it means? I'm not sure anyone needs to ever tell what that means, except the Python parser when it reads in the code and runs it (in the context of other code it also loaded). Obviously when code is being written out which can reconstruct a current object tree, then the writing process needs to understand what it means by each piece of code, especially as it might refer to previously defined bits to shorten or make more readable the output code file. But since it is writing the code, there should not be any ambiguities of intent. The hardest issue perhaps becomes making the results look as close to human written Python as possible (say, using "class" to define a class instead of making a plain object and turning it into a class by setting fields). > I can imagine a bit of interaction between the source and the runtime to > do this. For instance, we might see that "color" is bound to a specific > module, and "color.Color" to a specific object. We'll disallow certain > tricks, like binding "color" dynamically, monkeypatching something into > "color.Color", etc. Ultimately figuring out exactly what color.Color is > isn't *easy*, but at least it is feasible. > > Using existing introspection we can figure out some parts, some of the > sorts of things that IDEs with auto-completion figure out. They can > figure out what the arguments to Color() are and the docstring. Perhaps you are thinking about this from the point of view of something like PyDev parser, which reads Python code to syntax highlight it and perhaps provide code assistance. But, since the code has already been read, and we are manipulating the object tree directly, we know what everything means, because we just look at what the objects are directly by inspecting them. Granted, some of those objects represent code, and the code may be wrong or ambiguous or confusing from the users point of view, but that is ignorable by the code writer, which just writes out the snippet of code the way a user put it in. > But, you can also imagine adding an editor or other things to that > object; a richer form of __repr__, or a richer editable form than the > ASCII source. Maybe there would be a flag on Color that says it can be > called without side effect (meaning we can speculatively call it when > inspecting source); and then the resulting object might have something > that says it can be displayed in a certain way (with its real color), > and has certain slots you can edit and then turn into a new Color > invocation. I can see the value of all this from the GUI side, with various desired display options defined in the class or prototype. But again, Python object are (or should be :-) constructible from scratch without calling a class' init function. So, given that a writer can inspect an instance and just write out all the fields in its dictionary and their values it seems like we can write out any object (though perhaps it may need to recursively write out parts of embedded objects first, and then perhaps patch up circular references at the end). > This is where the 'make' syntax starts to come into play again, or more > generally where declarative source comes into play. Take a typical > non-declarative module, like optparse: I like what you outline and I see how something like it could make the code the output writer creates be more legible. > This is all harder than what HTConsole is doing currently, mostly > because Python source introspection is much poorer than Python object > introspection. Good point. And perhaps an area of Python that this project could work on? Can you elaborate on what parts of source introspection might need the most work and in what ways so that either programs or people can better inspect running Python programs? > Loading a Python program can already do anything, if you put the > commands at the top-level (not in a function). So Python source really > is focused on constructing objects -- even functions and classes are > *built* by the source, not declared by it, and so circular imports and > circular class references can be challenging as a result. True. But, the writer should be able to figure out how to handle this, perhaps using some sort of recursive process with a patch list and a cleanup routine? --Paul Fernhout From kirby.urner at gmail.com Sat May 6 09:41:42 2006 From: kirby.urner at gmail.com (kirby urner) Date: Sat, 6 May 2006 00:41:42 -0700 Subject: [Edu-sig] PySqueak: more on the cultural divide among paradigms In-Reply-To: <445C37AF.4050007@kurtz-fernhout.com> References: <445B8491.9070802@kurtz-fernhout.com> <445C37AF.4050007@kurtz-fernhout.com> Message-ID: On 5/5/06, Paul D. Fernhout wrote: > To recap, as I see it, this PySqueak effort gained some traction when you > and Guido cam back from the summit, having seen Alan Kay's presentation of > Squeak and Croquet. I'm sure it was dazzling, as Alan Kay is a captivating > speaker and Squeak and Croquet have a lot of really great features.(*) It wasn't like that. We sat around long tables and talked. No one had more than five minutes to do any kind of projected presentation thing. Croquet was mentioned in passing but never shown. Just wanting to keep the picture at least a little bit accurate. There's a wiki page with official notes, links to photographs Guido snapped with his cell phone (I'm disguised as a round looking man with shaggy gray hair). For another picture of me see here: http://mybizmo.blogspot.com/ scrolling down to Spring 2006. Kirby From pdfernhout at kurtz-fernhout.com Sat May 6 09:52:39 2006 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Sat, 06 May 2006 03:52:39 -0400 Subject: [Edu-sig] PySqueak: "Self" as the source of many ideas in Squeak In-Reply-To: <445BBEA6.1080900@colorstudy.com> References: <445B02D3.7060504@kurtz-fernhout.com> <445B7BB7.70609@colorstudy.com> <445B8AF6.7050200@kurtz-fernhout.com> <445BA4F4.9020102@colorstudy.com> <445BB27F.9000100@kurtz-fernhout.com> <445BBEA6.1080900@colorstudy.com> Message-ID: <445C55C7.1050908@kurtz-fernhout.com> Ian- Maybe we are still thinking about different things here. I'm going on the presumption that Python, like Smalltalk, have various "roots" which are things like (in Python) the loaded modules, the active threads and their stacks, and perhaps some other state. A Python world of objects is defined by these, since if any Python objects exist but are not reachable somehow, they can't effect the system. As I reflect on that, I can see how in theory outside forces that get a handle into object memory might make changes and such things might exist in other processes or threads, but that would just be a broken VM (or VM abstraction) to me more than a problem to solve. :-) So, going on this assumption that all Python objects of interest are reachable from these roots (even if some of the roots themselves might be only known to the VM, like the current thread?) then a recursive procedure can flow down through from these roots and write one big text file consisting of mainly: # big module import lots_of_stuff temp1 = object() temp1.__class__ = Point temp1.x = 10 temp1.y = 20 temp2 = object() temp2.__class__ = Point temp2.x = 40 temp2.y = 50 temp3 = object() temp3.__class__ = Rectangle temp3.origin = temp1 temp3.extent = temp2 modules.mymodule = object() modules.mymodule.__class__ = Module # or whatever? modules.mymodule.myrect = temp3 And so on. Now obviously this gets tedious, so an optimizing writer would instead produce: # module mymodule myrect = Rectangle(Point(10, 20), Point(40, 50)) But that's a matter of a smart writer, which I think is doable. Just think of it as like optimizing code (although maybe in reverse. :-) Now the problem you point out, that there may be several ways to reference an object is obviously a real one. But a smart writer should handle that (with a little handwaving by me. :-) But essentially, like with pickle, the writer would know it has to write the definition for a function out somewhere, and so it would pick a good spot, and then other references to that function could refer back to the first place it was defined. (Or it could be put in a temp variable which was later deleted after it was done being used.) Even if the writer picked a bad spot, the problem would only be that the code looked harder to read and understand, not that it would not recreate the same objects in memory that were written out (though perhaps at different locations; I'm presuming that would not matter -- if it did, then that might be a problem requiring VM changes or some fancy object creation order footwork, which would almost certainly mess up the code's readability). As I've just casually glanced at the CPython VM source code, and only just a bit more at the Jython code, I don't know enough off hand to see whether there might be other bigger problems. Anyway, I still don't see a show stopper (unless it is specific object ids or exact memory locations being important -- perhaps affecting dictionary hashes or some such thing?). Difficulties yes, maybe painful ones, but no showstopper so far as I can see to writing out running code as Python files (again, unless the above object ID issue). I can see that nicer source will likely result from tracking commands as the user defines them, as you suggest. But still, my focus isn't on readable source. That's more a nice to have feature from my set of priorities for GUI oriented construction and programming. What I am more interested in is, can the running program be changed, and can the changes be saved so they can be reloaded? So, our priorities may diverge there, but that's OK -- makes life interesting. :-) --Paul Fernhout Ian Bicking wrote: > Interactive sessions are source. The OB1 I referred to is the actual > object in memory, which has no real name, though it can be referenced > directly in memory. > > Maybe a better example is something in HTConsole right now. Any > function you can get your hands on in HTConsole is editable, in-place. > So you can do: > > >>> import random > >>> random.choice > > And you'll get a form that shows the source to that function, and lets > you edit it. That works fine in-memory. But saving that is hard. > > There's actually lots of ways to get access to a function. When you get > random.choice, you are actually getting access to a method of a > singleton stored in the random module. When you edit that, you are > editing the method. How do you represent that edit as source? Do you > see that the function is available as random.choice.im_func, or > random.Random.choice? Or a property, which might be available as > SomeClass.some_property.fget. There's lots of paths to functions, and > the function alone doesn't necessary know how to get to it. And > functions are relatively easy; other objects can be much harder... > > >>> items = range(5) > > The contents of items cannot be edited in place, because they are > recreated dynamically. They can only be modified by later commands. > > Keeping a log of commands is possible. But you aren't editing live > objects anymore, except perhaps an illusion of that. Instead you are > generating saveable commands from a specific location, which are > immediately executed to give you feedback but also saved so they can be > replayed in the future. > > As I've been thinking about this, I think command generation is pretty > much like direct source modification, but direct source modification > also leads to nice source. So that's why I'm thinking that live objects > isn't a good metaphor, after going down that path some. From pdfernhout at kurtz-fernhout.com Sat May 6 10:05:08 2006 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Sat, 06 May 2006 04:05:08 -0400 Subject: [Edu-sig] PySqueak: more on the cultural divide among paradigms In-Reply-To: References: <445B8491.9070802@kurtz-fernhout.com> <445C37AF.4050007@kurtz-fernhout.com> Message-ID: <445C58B4.4040709@kurtz-fernhout.com> kirby urner wrote: > On 5/5/06, Paul D. Fernhout wrote: > >>To recap, as I see it, this PySqueak effort gained some traction when you >>and Guido cam back from the summit, having seen Alan Kay's presentation of >>Squeak and Croquet. I'm sure it was dazzling, as Alan Kay is a captivating >>speaker and Squeak and Croquet have a lot of really great features.(*) > > > It wasn't like that. > > We sat around long tables and talked. No one had more than five > minutes to do any kind of projected presentation thing. > > Croquet was mentioned in passing but never shown. > > Just wanting to keep the picture at least a little bit accurate. Thanks for setting me straight on that. --Paul Fernhout From john.zelle at wartburg.edu Sat May 6 17:25:02 2006 From: john.zelle at wartburg.edu (John Zelle) Date: Sat, 6 May 2006 10:25:02 -0500 Subject: [Edu-sig] PySqueak: more on the cultural divide among paradigms In-Reply-To: <24d517dd0605051554j11622b10wcdfd1e92b4bbacb5@mail.gmail.com> References: <445B8491.9070802@kurtz-fernhout.com> <24d517dd0605051554j11622b10wcdfd1e92b4bbacb5@mail.gmail.com> Message-ID: <200605061025.02196.john.zelle@wartburg.edu> On Friday 05 May 2006 17:54, Dethe Elza wrote: > Would a VPython implemented on top of PyOpenGL be useful? Right now > VPython lives in its own world and doesn't play nice with native > windows, or PyGame, or OpenGL, or X3D, or OS X, or... The argument > for making writing it the way they have it to get the performance > necessary for physics demos. Meanwhile, Python has gotten faster, > machines have gotten *much* faster, and PyOpenGL is getting faster by > moving to a ctypes-based implementation. > > Would a pythonic 3D API, a la VPython, that plays well with others be > a valuable component for the Squeakification of Python? Or are we > talking apples and oranges (pythons and rubies)? > I've been thinking about just this sort of project. My hunch is that a Vpython in Python is now very doable using PyOpenGL. By building on OpenGL, most of the heavy graphics lifting can be done on the graphics card (even cheap ones are ridiculously fast these days). The OpenGL API is now standardized and stable for development, as long as one sticks to basic features for which hardware acceleration can be taken as a given. But OpenGL is not a modeling API, it's purely for drawing things. We need a higher-level standardized scene graph layer (ala VPython). This combination would make the entire graphics stack down to hardware Python based. VPython as it stands is very nice, but it is not extendable in Python. Want a more realistic shading model? No can do. Texture mapping? Out of luck. Stereo-modes? (well OK, but I had to do that in C++ ;-). It might be that something like the PyOpenGL Context code base could be used as a starting point. Along-side the modeling layer we need a good OpenGL-based gui toolkit as well. You really can't build a decent GUI in something like VPython. It would be nice if solid, good-looking applications could be built entirely on Python w/o having to introduce some other C/C++ dependencies. Relying only on OpenGL would give us a truly portable GUI kit (except for a very thin layer that glues it to the underlying windowing system ala GLUT). It could have a consistent, though not necessarily native look and feel anywhere OpenGL runs. I'm willing to give up native look and feel provided the toolkit looks great and has really snappy performance. Another approach would be to make the GUI themeable, so folks could easily implement themes to mimick standard native widget sets. Basing on OpenGL should provide these abilities. The entire X-library has now been impelemented on OpenGL, there's no reason in principle a decent OO gui framework couldn't also be built there (and there are already some candidates out there to use as models). <> > > I know I'd love to have a 3D environment that was both easy to use, > and extensible. Exactly. I agree that Vpython in Python would be a great start. <> > But Guido has committed that a Squeak-like GUI platform would be > welcome. So we are talking about extending the libraries to be more > encompassing. I agree about not extending the syntax (any more than > is already happening for Python 3000). > To me, it seems that a 2D/3D persistent scene-graph API paired with a GUI toolkit, both based on PyOpenGL is the obvious first step toward this goal. Alone, it would not really be very Squeak-like, but a Squeaky IDE needs the ability to describe a persisitent view (2D or 3D) as a basic starting point. On top of that foundation others can build the ultimate constructivist educational platform...or just some neat, useable 2D and 3D applications. Others could work on extending and improving the whole shebang without having to know any C or C++. The only question in my mind is how do we get started in making this vision a reality? I'd love to dive in and start working on it myself, but realistically, I've already got a lot of committments (writing is *$&% hard work :-). Where do we go from here? Ideas Dethe? By the way, how is the non-Fink port of Vpython for OSX going? We could really use that right now. My Mac students don't want to mess with Fink just to do a few Vpython projects. -- John M. Zelle, Ph.D. Wartburg College Professor of Computer Science Waverly, IA john.zelle at wartburg.edu (319) 352-8360 From winstonw at stratolab.com Sat May 6 18:40:09 2006 From: winstonw at stratolab.com (Winston Wolff) Date: Sat, 6 May 2006 12:40:09 -0400 Subject: [Edu-sig] PySqueak: more on the cultural divide among paradigms In-Reply-To: <200605061025.02196.john.zelle@wartburg.edu> References: <445B8491.9070802@kurtz-fernhout.com> <24d517dd0605051554j11622b10wcdfd1e92b4bbacb5@mail.gmail.com> <200605061025.02196.john.zelle@wartburg.edu> Message-ID: On May 6, 2006, at 11:25 AM, John Zelle wrote: > To me, it seems that a 2D/3D persistent scene-graph API paired > with a GUI > toolkit, both based on PyOpenGL is the obvious first step toward > this goal. As a former video games programmer, you definitely want to use OpenGL for the hardware acceleration. But I'd like some clarification on what this goal is. It seems like a lot of people are talking about lots of cool technology, but I've not read what we are trying to do with it. And of course we wouldn't want to build a technical solution in search of a problem. Everybody is talking about a new 3D GUI and IDE. What exactly are we trying to achieve by building a new GUI? What is wrong with existing Windows/X/Mac GUIs for an educational project? If we were talking about UI research then developing a new GUI system might be interesting, but for educational purposes, it seems like we have enough to do to achieve educational goals, without trying to redevelop a GUI system. -Winston ______________________________________________________ winston wolff - (646) 827-2242 - http://www.stratolab.com learning by creating - video game courses for kids in new york From pdfernhout at kurtz-fernhout.com Sat May 6 19:03:40 2006 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Sat, 06 May 2006 13:03:40 -0400 Subject: [Edu-sig] PySqueak: PataPata project with code on sourceforge Message-ID: <445CD6EC.8020900@kurtz-fernhout.com> There's no going back now. :-) I just committed some code to SVN on sourceforge so the "PataPata" project is here to stay. http://sourceforge.net/projects/patapata/ (You can't easily get sourceforge to remove something once it has code, so I've held back till now, though I requested the project about ten days ago.) The sourceforge blurb is: """PataPata brings constructivism to the Python platform, inspired by Squeak Smalltalk, but going beyond it in a Pythonic and abstraction-oriented way. PataPata can mean "Python Abstractly Touchable Applications -- Personalizable And Teachable Anywhere". """ (I'll probably be reworking what the letters mean as an acronym with community feedback, that's just a first cut. :-) You can view the first proof of concept code for prototypes here: http://svn.sourceforge.net/viewcvs.cgi/patapata/PataPata/proof_of_concept_001.py?view=markup Essentially it is just a few lines of Python defining a Prototype class and putting up a prototype widget with a TK widget class as a parent. Even that has issues, but it is a first step, but I'm trying to follow a "release early and often" mantra. Likely the project folders will soon get reorganized as the project grows, but SVN makes that fairly painless to do. Please note that this PataPata project is intended for the vision of PySqueak I have been outlining here, focusing on taking *ideas* from Squeak and Self and moving them to Python, as well as trying to go *beyond* the ideas in a Pythonic and constructivist way (in a "burn the disk packs approach"). The guiding theme is intended to be on making tools compatible with unschooling or "free schooling". School affiliated people are welcome to participate too, of course, if they find these constructivist ideas of use in the classroom for education and want to discuss such ideas. Or even if, sigh, they want a place to put curriculum materials for the classroom directly related to PataPata. It seems even Grace Llewellyn is writing a book related to getting the most out of your time in school: :-) http://www.edweek.org/tm/news/instruction/2004/03/01/05grace.h15.html But, in any case, supporting mainstream classroom specific issues (e.g. grading) is not something I myself will prioritize or encourage. If anyone wants to set up another PySqueak type project to do more of a direct port of Squeak and Croquet to Python, as well as to focus more on any specific schooling-related issues faced by the current Shuttleworth initiative, then by all means, please do so. And no hard feelings if someone else gets paid to do that. I might even try to contribute constructively to such a project occasionally. :-) While I've been taking advantage of discussions on the edusig list at the start to get some ideas kicked around (and thank you all for your forbearance :-), I just created a patapata-discuss list at sourceforge https://lists.sourceforge.net/lists/listinfo/patapata-discuss (though it will take about a day to show up apparently), so I'll start posting new stuff to there once the existing threads wind down here. By the way, "Pata Pata" is means "touch touch", which I think is appropriate for a project focusing on constructivist and direct manipulation Self-like and Squeak-like ideas. See: http://songsforteaching.homestead.com/PWM2PataPata.html for the South African song by Miriam Makeba that inspired the name. (There is even a link to a starting snippet of the project theme song there, from the Putumayo world music CD series we listen to. :-) --Paul Fernhout From johannes.wollard at gmail.com Sat May 6 20:58:58 2006 From: johannes.wollard at gmail.com (Johannes Woolard) Date: Sat, 6 May 2006 19:58:58 +0100 Subject: [Edu-sig] Google Summer of Code proposal Message-ID: <10c99c2a0605061158y193a5a8cja479661c5e03c197@mail.gmail.com> Hiya, I have revised an earlier proposal I posted through google summer of code, and was advised to post it on here. I have stuck it on the web at http://users.ox.ac.uk/~orie1763/coder-python.pdf Very briefly it is a proposal for a very basic IDE supporting a semi-interactive tutorials (I believe a couple of people on this list saw my original proposal) It would be great if anybody interested could have a look over it and give me feedback - and if anybody would like to mentor it (or something similar) please ccould they get back to me Thanks, Johannes Woolard -- Johannes Woolard, Oriel College, Oxford OX1 4EW 07837880296 ox extn: 26611 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20060506/7f56d335/attachment.html From ianb at colorstudy.com Sat May 6 23:35:05 2006 From: ianb at colorstudy.com (Ian Bicking) Date: Sat, 06 May 2006 16:35:05 -0500 Subject: [Edu-sig] PySqueak: "Self" as the source of many ideas in Squeak In-Reply-To: <445C45B4.9060503@kurtz-fernhout.com> References: <445B02D3.7060504@kurtz-fernhout.com> <445B7BB7.70609@colorstudy.com> <445C45B4.9060503@kurtz-fernhout.com> Message-ID: <445D1689.7000707@colorstudy.com> Paul D. Fernhout wrote: >>> I think that Ian's suggestion is the most sensible strategy for >>> proceeding >>> in that direction and continuing to maintain community interest in a >>> PySqueak inclined towards Self-like prototypes and a related GUI for >>> constructivist educational use (and other general use as well). >>> And if metaclasses turn out to not be the best approach, >>> still anything simple which preserves the Python syntax >>> while giving the new features (say, having all prototypes inherit from >>> a common class which overrides __getattr__ and __setattr__ to >>> simply look into the instance to find data and behavior?) >> I think it could be easier than that. I think a lot of the more >> declarative programming I do really has prototypes underneath it. >> (Ironically in Javascript I never find a need for prototypes, except to >> simulate classes.) > > Of course, you probably don't have a Self-like environment for Javascript. > :-) Or is there one? I've never done much with JavaScript. There are some more sophisticated development environments for Javascript, but I've never used any of them, only source editing. > Anyway, I tried to follow your example, but I am still left confused as to > how it is easier than creating GUI tools that manipulate all instances of > just one Prototype class? Your example still seems focused on making > classes. With one class, a few lines of code to search for values through > parent slots and you're done? Essentially, for any prototype-ish work, one > would just work with instances of this one class. Am I missing somethgin > vital here? Are you thinking about one class per one prorotype object? Is > that for performance reasons? I think my example confused you, since "class" was a misnomer. That is, you *can* subclass non-classes using the class statement. I was using that to mean "clone and update". I.e.: class foo(bar): def spam(self): print 'hi' That means "clone bar, and set foo.spam to this function". The use of the class statement is a little confusing, which is why I would like a make statement. To get to mechanics, basically this class statement means: foo = bar.__metaclass__('foo', (bar,), {'spam': spam_func}) So with the right fiddling you can "subclass" an instance. Anyway, I like the syntax, and find it more comfortable than direct assignment (especially for methods). For direct assignment, you might find the "magic_set" decorator I wrote useful: http://svn.colorstudy.com/home/ianb/ruby_blocks.py (toward the bottom) It lets you do: @magic_set(foo) def spam(self): print 'hi' which handles the closure to add instance methods directly to instances (which doesn't work if done just through assignment), among other assignments. It uses the name of the first argument (self, cls, or anything else) to determine what kind of function you are trying to create. -- Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org From kirby.urner at gmail.com Sat May 6 23:35:07 2006 From: kirby.urner at gmail.com (kirby urner) Date: Sat, 6 May 2006 14:35:07 -0700 Subject: [Edu-sig] PySqueak: more on the cultural divide among paradigms In-Reply-To: References: <445B8491.9070802@kurtz-fernhout.com> <24d517dd0605051554j11622b10wcdfd1e92b4bbacb5@mail.gmail.com> <200605061025.02196.john.zelle@wartburg.edu> Message-ID: > Everybody is talking about a new 3D GUI and IDE. What exactly are we > trying to achieve by building a new GUI? What is wrong with existing > Windows/X/Mac GUIs for an educational project? If we were talking > about UI research then developing a new GUI system might be > interesting, but for educational purposes, it seems like we have > enough to do to achieve educational goals, without trying to > redevelop a GUI system. > > -Winston I think your questions are on the money. If you've seen one of Miguel's demos of the new Novell desktop, you'll know we're already moving to more 3D motifs at the level of OS GUI, complete with the rotating cube between the six desktops, with a Quicktime movie able to wrap around an edge while still playing (flashing back to an OSCON). I think we'd like to be able to call up a writing surface, able to take source code, from within a 3D world, such as by unscrolling a canvas-like object plucked from a metallic tube, textures and everything. And as we've seen in Squeak, when every graphical type object has a strong shared set of base methods, then even buttons can be grabbed and tilted (not just depressed). Per recent Mono or .NET presentations of IronPython: so you want every button on your GUI calculator rotated counter-clockwise by 45 degrees? No problem. That's just the trend in GUIs these days, with GNOME very much a trailblazer (wow, svg screen icons!). So the engines I'm envisioning at some level might just be the next generation OSs of choice, and their accompanying GUI session managers. If sufficiently integrated and interoperable (we have a ways to go), we might call this Squeaky clean. Think Emacs = eToy. But I don't think we can stop there. More specialized apps, on top of the OSs, will provide their own vocabulary of 3D components (objects), be they widget type, animal type, or whatever. You'll be able to script their behaviors and interactions, oft times by typing, as the base source continues to be lexical (versus say hieroglyphic, which more characterizes the desktop icons level). Such applications entail an event model, lots of hooks, and mechanisms for persistence across sessions. The OS offers an API for all of this, yes, but not always at a high enough level. By design. Managing some "higher level" is not really the OS's job. A layer of "education applications" wrapped around various spatial geometry animation engines is reasonable to anticipate, plus I expect many of them will come with Python bindings, although not necessarily exclusively (any number of languages should be enabled to play, by giving them some shared target language -- precisely the intent of the .NET design, and Parrot's). Kirby From kirby.urner at gmail.com Sat May 6 23:55:12 2006 From: kirby.urner at gmail.com (kirby urner) Date: Sat, 6 May 2006 14:55:12 -0700 Subject: [Edu-sig] PySqueak: more on the cultural divide among paradigms In-Reply-To: References: <445B8491.9070802@kurtz-fernhout.com> <24d517dd0605051554j11622b10wcdfd1e92b4bbacb5@mail.gmail.com> <200605061025.02196.john.zelle@wartburg.edu> Message-ID: I cropped and blogged my previous post and added some hyperlinks for the benefit of readers who might want more decrypting of this particular alphabet soup, other allusions. http://worldgame.blogspot.com/2006/05/blabbing-on-edu-sig.html Kirby From pdfernhout at kurtz-fernhout.com Sun May 7 00:13:16 2006 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Sat, 06 May 2006 18:13:16 -0400 Subject: [Edu-sig] PySqueak: more on the cultural divide among paradigms In-Reply-To: References: <445B8491.9070802@kurtz-fernhout.com> <24d517dd0605051554j11622b10wcdfd1e92b4bbacb5@mail.gmail.com> <200605061025.02196.john.zelle@wartburg.edu> Message-ID: <445D1F7C.1020707@kurtz-fernhout.com> Winston Wolff wrote: > On May 6, 2006, at 11:25 AM, John Zelle wrote: > But I'd like some clarification on what this goal is. I don't think there is total agreement on that (or ever will be). Speaking for myself, my goal it to support educational constructivism on the Python platform, inspired by "Squeak" and "Self", but going beyond those in a Pythonic way. I mainly want to support support "unschooling", "free schooling", and "informal" education (though other uses are possible, of course, like in the classroom). And here is a sourceforge project to that end: :-) http://sourceforge.net/projects/patapata/ The mailing list is now active here: https://lists.sourceforge.net/lists/listinfo/patapata-discuss > Everybody is talking about a new 3D GUI and IDE. What exactly are we > trying to achieve by building a new GUI? What is wrong with existing > Windows/X/Mac GUIs for an educational project? Take a look at this video on the "Self" programming language and environment to see part of what inspires me: http://www.smalltalk.org.br/movies/ But if you just want the overview, consider: http://research.sun.com/self/papers/programming-as-experience.html Now, Squeak and Croquet have their own twist on this as well producing other ideas worthy of consideration. Lots of resources on the web on those and related issues are linked here: http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-September/095155.html > If we were talking > about UI research then developing a new GUI system might be > interesting, but for educational purposes, it seems like we have > enough to do to achieve educational goals, without trying to > redevelop a GUI system. UI Research? :-) Croquet is about five years old. Squeak is about ten years old. Self is about twenty years old. Smalltalk is about thirty years old. Key aspects of these development environments are still missing in mainstream Python development IMHO (e.g coding in the debugger, graphically manipulating data structures, fine grained version control, prototype-oriented development, modifying running programs, effortlessly saving a living world of objects, transparently drilling down through the system, easily coordinating multiple developers using all the above tools on the same object space, and so on). Not to say you can't do a little of some of these with existing tools in Python, of course. It's more a matter of degree and integration. It certainly generally is not easy. As a developer, I want as many of these features as possible under a Python GUI and IDE to develop extendable educational simulations. As an educator, I think learners will benefit from them as well, whether they are learning to program or learning to master the content of a simulated microworld. Now obviously, when one tries to think about doing these older things on a newer platform like Python, with its own culture and strengths and weaknesses, some R&D is required to adapt them to that new framework. And of course, while one is doing that, it would be interesting and motivating to think about doing something even better than what went before, rather than simply reinvent the wheel (or port it :-). But, as Kirby rightly points out, Python-as-it-is is quite serviceable for self-education, and so are existing GUIs. If you are content with that, then go for it! --Paul Fernhout From pdfernhout at kurtz-fernhout.com Sun May 7 01:25:08 2006 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Sat, 06 May 2006 19:25:08 -0400 Subject: [Edu-sig] PySqueak: "Self" as the source of many ideas in Squeak In-Reply-To: <445D1689.7000707@colorstudy.com> References: <445B02D3.7060504@kurtz-fernhout.com> <445B7BB7.70609@colorstudy.com> <445C45B4.9060503@kurtz-fernhout.com> <445D1689.7000707@colorstudy.com> Message-ID: <445D3054.3070808@kurtz-fernhout.com> Ian Bicking wrote: > Paul D. Fernhout wrote: > I think my example confused you, since "class" was a misnomer. That is, > you *can* subclass non-classes using the class statement. I was using > that to mean "clone and update". OK, that makes more sense to me, and now I can see the cleverness of it. Took a while; thanks for being patient with me. :-) And thanks for the pointer to your other stuff and magic set. I'm a big fan of those collection block operations BTW (although they came from Smalltalk before Ruby :-). Is that stuff under the Python license, or something else? I might want to put it into PataPata, and I hope to use the Python/Jython license for core classes, and then the GPL for any stand-alone applications. --Paul Fernhout From ianb at colorstudy.com Sun May 7 02:00:54 2006 From: ianb at colorstudy.com (Ian Bicking) Date: Sat, 06 May 2006 19:00:54 -0500 Subject: [Edu-sig] PySqueak: "Self" as the source of many ideas in Squeak In-Reply-To: <445C4F7D.70104@kurtz-fernhout.com> References: <445B02D3.7060504@kurtz-fernhout.com> <445B7BB7.70609@colorstudy.com> <445B8AF6.7050200@kurtz-fernhout.com> <445BA4F4.9020102@colorstudy.com> <445C4F7D.70104@kurtz-fernhout.com> Message-ID: <445D38B6.9000001@colorstudy.com> Paul D. Fernhout wrote: > Ian Bicking wrote: >> This is all not to say that modifying Python source in a manner >> different than ASCII is infeasible. Only that "source" and "runtime" >> have to be kept separate to keep this process sane. Images -- which >> mingle the two -- have never felt sane to me; clever, but not >> manageable. > > Well, perhaps sanity is overrated. :-) > > And Smalltalk has been managing this for thirty years. :-) > > But it is true, it requires a bunch of special purpose tools. Changeset > browsers. A change log. External source code control. Image cloners. and > so on. Probably a Python that stored a running image as Python program > files might need some specialized tools too. Zope went down that path with through-the-web development with the ZODB as the image. I think everyone agrees that didn't work. Smalltalk has pursued that with more vigor, but I was never comfortable with the image. In some ways you can read my comments as me figuring out just why I dislike the image model. I think it's important to figure out, because the image model seems very compelling for an education environment. > > Unfortunately we do not have very good abstractions in >> Python related to source, so they have to be invented from scratch. The >> AST might help, but higher-level abstractions are also called for. For >> instance, you might define a color interactively in some fashion, and >> the color gets serialized to: >> >> import color >> color.Color(r, b, c) >> >> That color object might be immutable (probably should be), but the >> *source* isn't immutable, and the source means something. How can we >> tell what it means? > > I'm not sure anyone needs to ever tell what that means, except the Python > parser when it reads in the code and runs it (in the context of other code > it also loaded). Obviously when code is being written out which can > reconstruct a current object tree, then the writing process needs to > understand what it means by each piece of code, especially as it might > refer to previously defined bits to shorten or make more readable the > output code file. But since it is writing the code, there should not be > any ambiguities of intent. The hardest issue perhaps becomes making the > results look as close to human written Python as possible (say, using > "class" to define a class instead of making a plain object and turning it > into a class by setting fields). With the color example, I'm really thinking about richer kinds of source literals. Maybe color.Color(1, 0, 0) is a better example. You can statically determine that is "red", and you could display it as red. And maybe it's not that much of a stretch to think about the program as a set of these objects. They aren't live objects, and they aren't entirely equivalent to the live objects. So a function definition is a source object; the function itself is the runtime object. We can treat them as equivalent, until we get to the point that we want to update things. >> I can imagine a bit of interaction between the source and the runtime to >> do this. For instance, we might see that "color" is bound to a specific >> module, and "color.Color" to a specific object. We'll disallow certain >> tricks, like binding "color" dynamically, monkeypatching something into >> "color.Color", etc. Ultimately figuring out exactly what color.Color is >> isn't *easy*, but at least it is feasible. >> >> Using existing introspection we can figure out some parts, some of the >> sorts of things that IDEs with auto-completion figure out. They can >> figure out what the arguments to Color() are and the docstring. > > Perhaps you are thinking about this from the point of view of something > like PyDev parser, which reads Python code to syntax highlight it and > perhaps provide code assistance. But, since the code has already been > read, and we are manipulating the object tree directly, we know what > everything means, because we just look at what the objects are directly by > inspecting them. Granted, some of those objects represent code, and the > code may be wrong or ambiguous or confusing from the users point of view, > but that is ignorable by the code writer, which just writes out the > snippet of code the way a user put it in. You can't know much about the objects inside a function, because they aren't bound to anything. You can know about objects defined at the module level. So even with runtime interaction you really can't do a whole lot better than PyDev. >> But, you can also imagine adding an editor or other things to that >> object; a richer form of __repr__, or a richer editable form than the >> ASCII source. Maybe there would be a flag on Color that says it can be >> called without side effect (meaning we can speculatively call it when >> inspecting source); and then the resulting object might have something >> that says it can be displayed in a certain way (with its real color), >> and has certain slots you can edit and then turn into a new Color >> invocation. > > I can see the value of all this from the GUI side, with various desired > display options defined in the class or prototype. But again, Python > object are (or should be :-) constructible from scratch without calling a > class' init function. I don't understand what you mean here? Most objects aren't constructible from scratch. Many objects are immutable, and can only be recreated, not modified. > So, given that a writer can inspect an instance and > just write out all the fields in its dictionary and their values it seems > like we can write out any object (though perhaps it may need to > recursively write out parts of embedded objects first, and then perhaps > patch up circular references at the end). You mean pickle? >> This is all harder than what HTConsole is doing currently, mostly >> because Python source introspection is much poorer than Python object >> introspection. > > Good point. And perhaps an area of Python that this project could work on? > Can you elaborate on what parts of source introspection might need the > most work and in what ways so that either programs or people can better > inspect running Python programs? There's a bunch of pieces. There's work already done on many of them, and people (particularly in the IDE crowd) interested in refining that work. It's not something I've done a lot with, but here's some non-obvious pieces: * Better source code readers. Perhaps the work on a Python API to the AST would help here. Python 2.5 introduces a better internal model for source (the AST), but actual access to that isn't worked out yet. It's important to know how that abstract structure maps to actual source; right now I think it just has a line-level granularity. * The decompiling tools might be useful. There's already several; I know they drop things, but I don't know what. I think they do pretty well. If things like comments lived in the AST, that'd be great, but they don't currently. I think some variable names might be lost too, but I'm not sure. * Tools to figure out the relations between modules. Or maybe more generally, just a way of determining as much as possible statically. PyChecker and other tools do this some. It doesn't have to be perfect. * We can only really work with modules that can be safely imported and do not care about their environment. Lots of modules aren't like that, but I think those modules should just be given up on, or they need to be fixed. PyChecker and other projects have to worry about this a lot, and it's just not worth it -- environment-dependent modules just suck and need to be fixed. And maybe that's mostly it. The AST seems most important, though current tools actually do a lot of the necessary parts. So, for instance, I was stressed out about how a function gets edited in place. But maybe that doesn't need to be too hard. A function usually has a reference to where it comes from (the file and line number). You could then parse the code to figure out where the function ends. Then you rewrite the file with the new function definition, indented to the same level as the old function definition. Few other objects carry their source information. Modules do (just their __file__). Classes do not, nor do attributes or other assignments, and objects like lists often have no direct representation in the source. But classes are easy enough to figure out by just looking at the source, and at least they carry their original name. Well, at least this makes me feel a little better about what I want to do with HTConsole. I just have to avoid editing objects that are not obviously represented by source. I.e., you can edit/reassign variables and class attributes and functions, but not instances or lists. -- Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org From kirby.urner at gmail.com Sun May 7 02:37:22 2006 From: kirby.urner at gmail.com (kirby urner) Date: Sat, 6 May 2006 17:37:22 -0700 Subject: [Edu-sig] Pythonic Mathematics (session 3) Message-ID: On 4/30/06, kirby urner wrote: > CLASS: Saturday Academy: Pythonic Mathematics > LOCATION: Portland State University, Neuberger Hall > TIME: 10 AM - 12:30 PM > I chose a different forum for the next session: http://mathforum.org/kb/thread.jspa?threadID=1377897 I'm working to interest community college teachers in the Gnu Math approach. Kirby From john.zelle at wartburg.edu Sun May 7 03:08:24 2006 From: john.zelle at wartburg.edu (John Zelle) Date: Sat, 6 May 2006 20:08:24 -0500 Subject: [Edu-sig] PySqueak: more on the cultural divide among paradigms In-Reply-To: References: <445B8491.9070802@kurtz-fernhout.com> <200605061025.02196.john.zelle@wartburg.edu> Message-ID: <200605062008.24521.john.zelle@wartburg.edu> On Saturday 06 May 2006 11:40, Winston Wolff wrote: > On May 6, 2006, at 11:25 AM, John Zelle wrote: > > To me, it seems that a 2D/3D persistent scene-graph API paired > > with a GUI > > toolkit, both based on PyOpenGL is the obvious first step toward > > this goal. <> > But I'd like some clarification on what this goal is. It seems like > a lot of people are talking about lots of cool technology, but I've > not read what we are trying to do with it. And of course we wouldn't > want to build a technical solution in search of a problem. > > Everybody is talking about a new 3D GUI and IDE. What exactly are we > trying to achieve by building a new GUI? What is wrong with existing > Windows/X/Mac GUIs for an educational project? If we were talking > about UI research then developing a new GUI system might be > interesting, but for educational purposes, it seems like we have > enough to do to achieve educational goals, without trying to > redevelop a GUI system. Kirby has already weighed in with his grand vision. My goals are much more modest (though not necesarily in opposition). Winston is right that there are lots of great tools available now, an embarrasment of riches so to speak. We can and should plunge ahead with educational materials. Still I have an itch that is currently not scratchable, and I think requires reinventing the wheel. I am looking at Python as a learning environment for computer science, as a platform for building compelling educational material (e.g., bringing VR to the classroom), and as a sandbox for all kinds of experimentation. Here's what I don't have now: 1) An easy to use 3D environment (ala VPython) that is extendable in Python. When I need realistic materials or textures, I want to be able to add that without having to wait for the C++ gurus to put it into their library for me or having to wade into that muck myself. 2) A solid, easy to program cross-platform GUI toolkit that integrates with #1. I cannot now reliably develop, say, on Linux and expect that my students with various flavors of Windows and Macs will get the same experience. Educational apps/IDEs/enviroments need to be rock solid, snappy, and consistent across platforms. We really don't have that now. There are always extra layers and external dependencies that get in the way. Maybe PyQT4 will solve this one? 3) A simple to use GUI builder (ala Visual BASIC, but more basic ;-) for #2 to take the tedium out of widget placement. 4) For CS education (and all those interested in knowing how computers really work), it would be great if the Python graphics stack went all the way down to the machine (actually OpenGL) level. Like Squeak, but using hardware acceleration. Then everyone has a ticket to play just by learning Python and showing some curiousity. Can we program a modern 3D game, for example, in Python? Or is knowledge of C++ the price of admission. I don't know, and I'd like to find out. I think #4 is where I part company with Kirby. I'm not looking for some machine-level 3D libraries that are scripted via Python (or another high-level language, ala Alice). I want the snake all the way down, and I want the underlying graphics engine to be installed everywhere Python lives with OpenGL, so that I can count on it. I know I'm asking a lot, but I also think it's all doable. This to me would be the foundation for a "better than Squeak" Python environment. The "saving the state" issue seems secondary to this basic foundation. How can we even talk about saving the state of widgets that we don't "own." -- John M. Zelle, Ph.D. Wartburg College Professor of Computer Science Waverly, IA john.zelle at wartburg.edu (319) 352-8360 From kirby.urner at gmail.com Sun May 7 03:39:00 2006 From: kirby.urner at gmail.com (kirby urner) Date: Sat, 6 May 2006 18:39:00 -0700 Subject: [Edu-sig] Errors in Wikipedia entry for IronPython? Message-ID: I have a problem with this example code: from BookService import BookDictionary booksWrittenByBookerPrizeWinners = [] for book in BookDictionary.GetAllBooks: if "Booker Prize" in book.Author.MajorAwards: booksWrittenByBookerPrizeWinners.append(book.Title) booksWrittenByBookerPrizeWinners First, the variable names seem intentionally ugly, but I'm not going to worry about that. What really bugs me is BookDictionary.GetAllBooks without making it callable. The prefixing verb Get would imply a function, and Python distinguishes itself from Ruby (per Martelli) by making a sharp distinction between a function *named* and a function *called*. Perhaps its just an unfortunate naming issue, i.e. GetAllBooks is really to be thought of as an iterable, not a function call. Under the hood, there might be some property, i.e. if it has to consult a database (whatever BookService does). But in that case, I'd really prefer a function with no arguments, a callable in other words. Anyway, as you can see, I'm unhappy with this code. Plus there's a clear typo in the next sentence: "In this case, assume that the .NET framework implements a class, BookDictionary, in a module called BookService, and publishes an interface into which IronPython scripts can be sent and exectuted." I've edited Wikipedia before, but hesitate to dive in on this one without more seasoning (comments?). Kirby From kirby.urner at gmail.com Sun May 7 04:48:42 2006 From: kirby.urner at gmail.com (kirby urner) Date: Sat, 6 May 2006 19:48:42 -0700 Subject: [Edu-sig] PySqueak: more on the cultural divide among paradigms In-Reply-To: <200605062008.24521.john.zelle@wartburg.edu> References: <445B8491.9070802@kurtz-fernhout.com> <200605061025.02196.john.zelle@wartburg.edu> <200605062008.24521.john.zelle@wartburg.edu> Message-ID: On 5/6/06, John Zelle wrote: > I think #4 is where I part company with Kirby. I'm not looking for some > machine-level 3D libraries that are scripted via Python (or another > high-level language, ala Alice). I want the snake all the way down, and I > want the underlying graphics engine to be installed everywhere Python lives > with OpenGL, so that I can count on it. I should be quiet and study Panda3D for awhile. http://panda3d.org/ That may be what I try teaching through Saturday Academy in the Fall. Kirby From aharrin at luc.edu Sun May 7 05:21:01 2006 From: aharrin at luc.edu (Andrew Harrington) Date: Sat, 06 May 2006 22:21:01 -0500 Subject: [Edu-sig] PySqueak: more on the cultural divide among paradigms In-Reply-To: References: <445B8491.9070802@kurtz-fernhout.com> <200605061025.02196.john.zelle@wartburg.edu> <200605062008.24521.john.zelle@wartburg.edu> Message-ID: <445D679D.2080806@luc.edu> I just looked at Panda3D. The export restrictions in the license are troublesome. Another obvious drawback in the intro is the reference only to Windows and Linux, not Apple. I do not know if that might change with Apple moving to Intel. Sigh, for a Linux or Windows lab in the US, it looks nice, but for our general community projects, platform and country independence are important.. Andy kirby urner wrote: >On 5/6/06, John Zelle wrote: > > > >>I think #4 is where I part company with Kirby. I'm not looking for some >>machine-level 3D libraries that are scripted via Python (or another >>high-level language, ala Alice). I want the snake all the way down, and I >>want the underlying graphics engine to be installed everywhere Python lives >>with OpenGL, so that I can count on it. >> >> > >I should be quiet and study Panda3D for awhile. > >http://panda3d.org/ > >That may be what I try teaching through Saturday Academy in the Fall. > >Kirby >_______________________________________________ >Edu-sig mailing list >Edu-sig at python.org >http://mail.python.org/mailman/listinfo/edu-sig > > -- Andrew N. Harrington Computer Science Department Undergraduate Program Director Loyola University Chicago http://www.cs.luc.edu/~anh 512B Lewis Towers (office) Office Phone: 312-915-7982 Snail mail to Lewis Towers 416 Dept. Fax: 312-915-7998 820 North Michigan Avenue aharrin at luc.edu Chicago, Illinois 60611 From pdfernhout at kurtz-fernhout.com Sun May 7 06:09:16 2006 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Sun, 07 May 2006 00:09:16 -0400 Subject: [Edu-sig] PySqueak: "Self" as the source of many ideas in Squeak In-Reply-To: <445D1689.7000707@colorstudy.com> References: <445B02D3.7060504@kurtz-fernhout.com> <445B7BB7.70609@colorstudy.com> <445C45B4.9060503@kurtz-fernhout.com> <445D1689.7000707@colorstudy.com> Message-ID: <445D72EC.9030806@kurtz-fernhout.com> Ian- Thanks again for this pointer. I've added two more proof of concept files to PataPata. The second one demonstrates inheritance with a parent and two children, as well as graphically displaying the morphs. See: http://svn.sourceforge.net/viewcvs.cgi/patapata/PataPata/proof_of_concept_002.py?view=markup I started trying to do it in OpenGL (which I have had working before) and got some errors so punted and chose wx and 2D for that. I don't like making initial proof of concepts that rely on too many dependencies. OpenGL remains a real possibility down the road, but this one problem just shows how installation issues can bite you (in this case, I had commented out the driver for it in my xorg.conf file when I was having other problems related to one of my two ATI cards having problems driving its secondary display head, and didn't care to restart X in the middle of my development to try fixing that.) The third P.O.C. demonstrates the problem your solution addresses. http://svn.sourceforge.net/viewcvs.cgi/patapata/PataPata/proof_of_concept_003.py?view=markup I found two other variants of solutions on the web (differences include are who does the wrapping etc.), and I need to decide how best to proceed on that. Links to these three options including yours: http://svn.colorstudy.com/home/ianb/ruby_blocks.py http://zephyrfalcon.org/weblog/arch_d7_2002_11_16.html http://lists.canonical.org/pipermail/kragen-hacks/2000-September/000264.html [The latter two are more specific to Prototype inheritance in Python.] Going to be traveling much of next week, so probably not much more activity on this for a while. Frustrating to me as I think this is just picking up some speed. A little OpenGL, a few Self-like GUI widgets for inspecting values like in the movie of just rectangles and lines and text, using a wrapper approach for inserting methods into prototypes, adding a remote debugging process perhaps derived from Idle, making some program writing code derived from pickle perhaps, dropping in some bitmap and icon content from our garden simulator, and the result might be a nice proof of concept constructivist educationally-oriented system in a week's work or so. Obviously not everything, and with very rough edges, but something that could show the basic ideas. Sigh. With distractions, and part-time, be nice to get all that together by the end of June, if that, realistically. No promises though. Thanks again for your feedback. --Paul Fernhout Ian Bicking wrote: > For direct assignment, you might find the "magic_set" decorator I wrote > useful: http://svn.colorstudy.com/home/ianb/ruby_blocks.py (toward the > bottom) > > It lets you do: > > @magic_set(foo) > def spam(self): print 'hi' > > which handles the closure to add instance methods directly to instances > (which doesn't work if done just through assignment), among other > assignments. It uses the name of the first argument (self, cls, or > anything else) to determine what kind of function you are trying to create. From kirby.urner at gmail.com Sun May 7 06:10:55 2006 From: kirby.urner at gmail.com (kirby urner) Date: Sat, 6 May 2006 21:10:55 -0700 Subject: [Edu-sig] PySqueak: more on the cultural divide among paradigms In-Reply-To: <445D679D.2080806@luc.edu> References: <445B8491.9070802@kurtz-fernhout.com> <200605061025.02196.john.zelle@wartburg.edu> <200605062008.24521.john.zelle@wartburg.edu> <445D679D.2080806@luc.edu> Message-ID: > Sigh, for a Linux or Windows lab in the US, it looks nice, but for our > general community projects, platform and country independence are > important.. > > Andy > I haven't studied the license carefully. I did notice a version for Ubuntu in the downloads section. Anyway, I think experience with Panda3D will help me think about these issues we've been grappling with of late (Python vis-a-vis stronger graphics) -- whether or not this tool becomes widely adopted in say the TuxLab setting. Thanks for your heads up though. The wrong licensing does have a way of killing an otherwise promising initiative. Kirby From pdfernhout at kurtz-fernhout.com Sun May 7 16:11:23 2006 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Sun, 07 May 2006 10:11:23 -0400 Subject: [Edu-sig] PySqueak: more on the cultural divide among paradigms In-Reply-To: <200605062008.24521.john.zelle@wartburg.edu> References: <445B8491.9070802@kurtz-fernhout.com> <200605061025.02196.john.zelle@wartburg.edu> <200605062008.24521.john.zelle@wartburg.edu> Message-ID: <445E000B.4050709@kurtz-fernhout.com> John Zelle wrote: > [Thoughtful outline of important design point > (and differences in priorities) snipped.] > I know I'm asking a lot, but I also think it's all doable. This to me would be > the foundation for a "better than Squeak" Python environment. The "saving the > state" issue seems secondary to this basic foundation. How can we even talk > about saving the state of widgets that we don't "own." On saving the state of non-Python widgets we don't own, in theory, a well written widget set like wxWindows should support queries on all the states of all widgets. Still, in practice, sometimes they assume you will remember externally what state you set something to, especially if they pass the value on to another layer (like the OS). For example, what if a bitmap is somehow converted into a native representation and the original discarded (not sure this is a problem, just making one up)? But I think those cases could be ignored at the start? And then treated as bugs in the widget set API? Clearly the most common things for having a list or text box selection or label, those should all be queryable. But, having not tried to do this, there could easily be unexpected gotchas, especially moving across multiple widget sets. I know in years past I have had this problem of missing accessors when writing code for applications that want to restore their exact window layout on reopening. And clearly, you could not move a saved image to a platform without bindings (and probably the same version of bindings) for the widget set the image was saved using. But in any case, while this is a vexing problem, and likely entails writing lots of widget specific code for each widget set, essentially it just involves creating a function for each type of widget that knows how to query and restore its state. However, obviously, that is a lot of code, and then it has to be maintained, and perhaps special cases ad widget sets changed. So, mostly doable I think (especially with something like wx, where you can submit changes to the project to fix access "bugs"), but a pain. But I agree that if you design your own widget set using Python code, and it is represented by Python objects, then any major concerns about this save/restore issue go away. And I don't think this is reinventing the wheel as much as one might think, becuase any project with a compatible license coudl be looked at to get ideas or code for these basic widgets. For example, Lazarus and FPC if you can live with the LGPL license (and I conveniently have written a Delphi->Python translator that does 80% of the translation work. :-) And I'm thinking now that even just the basics (using native fonts, like with a wx canvas) might be good enough for a proof of concept system, since you can do a lot quickly with a just text, icons, lines, and colored boxes (even without embedding dynamically generated bitmaps and bitblit!). You can build a whole development environment with mainly lists and menus (a wrapping text box for code is the hardest part). But it will probably look like the first released (1.13?) version of Squeak (until a lot of more work gets done). :-) --Paul Fernhout From kirby.urner at gmail.com Sun May 7 17:06:40 2006 From: kirby.urner at gmail.com (kirby urner) Date: Sun, 7 May 2006 08:06:40 -0700 Subject: [Edu-sig] Pythonic Mathematics (session 3) In-Reply-To: References: Message-ID: > > CLASS: Saturday Academy: Pythonic Mathematics > > LOCATION: Portland State University, Neuberger Hall > > TIME: 10 AM - 12:30 PM > > > > I chose a different forum for the next session: > http://mathforum.org/kb/thread.jspa?threadID=1377897 > > I'm working to interest community college teachers in the Gnu Math approach. > > Kirby I followed up with an erratum. I actually got it right in the presentation itself: called it Euclid's Algorithm, not Euler's (in the writing, I was thinking ahead to Euler's Theorem, which colored my lead-up; call it foreshadowing). What I don't give myself credit for in the above-cited write-up, is my excellent representation of Ada's role in things, as a bright, gorgeous, dare I say fetching socialite, daughter of a great poet, yet able to speculate accurately as to what "programming" might look like. Enter Bernoulli numbers. Babbage, on the other hand, was not nearly so effective in promoting his machine to VCs. He needed her as a fan, and perhaps got more than he bargained for. Anyway, I do enjoy math-through-storytelling. I'm not such a master as QuickSilver's author, but I still manage to write a good script. OK, enough with the self promotion already. Kirby From pdfernhout at kurtz-fernhout.com Sun May 7 17:08:35 2006 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Sun, 07 May 2006 11:08:35 -0400 Subject: [Edu-sig] PySqueak: "Self" as the source of many ideas in Squeak In-Reply-To: <445D38B6.9000001@colorstudy.com> References: <445B02D3.7060504@kurtz-fernhout.com> <445B7BB7.70609@colorstudy.com> <445B8AF6.7050200@kurtz-fernhout.com> <445BA4F4.9020102@colorstudy.com> <445C4F7D.70104@kurtz-fernhout.com> <445D38B6.9000001@colorstudy.com> Message-ID: <445E0D73.4010908@kurtz-fernhout.com> Ian Bicking wrote: > Zope went down that path with through-the-web development with the ZODB > as the image. I think everyone agrees that didn't work. Smalltalk has > pursued that with more vigor, but I was never comfortable with the > image. In some ways you can read my comments as me figuring out just > why I dislike the image model. Well, everyone? :-) Check out http://www.1010wins.com/ for what was, last I heard, a major Zope site. Still, a lot of peopel agree with you, so there are clearly issues here. For all I know, that group is unhappy? I myself like images you can build from text when you want to, but that has never been the focus of most Smalltalks (and isn't for Squeak so far). But, I think a truly Pythonic approach might insist on building objects from text, although it is true that we have pickle, which uses text, but not as a Python program. > I think it's important to figure out, because the image model seems very > compelling for an education environment. And John also made some of those points indirectly. I think from a "classroom" standpoint, teachers generally want to be in control of what the student sees, at least at first, and they also have short classes ("45 minutes) where they do not want to waste time on configuration. So, preparing an image for kids and seeing it pop up exactly like you made it, whatever the hardware (like Squeak can do) is a big win in a classroom setting. Of course, I'm not big on conventional classrooms :-), but I think images are desirable for independent or informal learning as well, which can happen in fits and starts, where you might do something intensely for days and then not revisit something until months later. And it would be nice if everything was just the way you left it. Also, as a developer of (hopefully open) educational simulations, I see the value in being able to deploy the simulation as an image which people could then modify to their own needs. So this is an area of overlap regardless of educational paradigm. Granted though, if you want to learn about the details of the machine you are on, or the notion of a software stack, like Kirby pointed to a week or two ago, in terms of getting into the specifics of GNU/Linux, then images are hiding stuff you might want to make visible. (Of course, you could open a terminal window from your running image. :-) I think a big issue with "images" is that they presume that you will put in the time to learn the tools assembled in the image (assuming the image is mainly about learning programming) rather than use some older ones you are comfortable with already. It is much easier to type text on the command line or use your favorite text editor than to learn an IDE (especially when you are learning a new language at the same time). But the value of learning an IDE can be immense in terms of letting you manage complexity far beyond what you can do with a text editor. It is funny how we can all accept that learning to play a musical instrument like the flute might take years of concentrated study to even get a good "tone" out of it, but we expect computers to be engaging on a minute by minute basis. Or, we just accept that learning to touch type takes days of practice. But computer IDEs? Do they really need to be like video games, engaging and addictive from the first quarter? John Holt wrote on this when he talked about "hard fun" (also mentioned here recently in another context I think) and how playing music, considering the suffering involved to get good at it, could hardly be described as "fun", but there certainly is something there for many people that keeps it engaging as a transcendental experience (as a sense of "flow"). Still, I think people here are right when they suggest typing at the command line an doing text processing produces feedback that keeps people engaged. The question is, can a graphical IDE do that, and I think the answer with Self might usually be "yes". I think the answer with "Squeak" is sometimes "no" though, but I have real experience with that, and have still never used Self. :-) Still, the "E" in CP4E is about "Everyone", so I can see the value in trying to make things accessible to broader audiences. My hope is that both the expert and the novice can be satisfied by a better system, and I think "Self" (or to a lesser extent "Squeak") helps show that way, prudcing a system I can love as an expert, but (taking their word for it, at least for Self :-) I think novices can warm to quickly as well. That gets back to the point I made on innovation -- satisfying both needs at once (e.g. expert and novice both love it) rather than compromising somewhere between them (e.g. not so hard for novices, but not so interesting for experts). >>I can see the value of all this from the GUI side, with various desired >>display options defined in the class or prototype. But again, Python >>object are (or should be :-) constructible from scratch without calling a >>class' init function. > > > I don't understand what you mean here? Most objects aren't > constructible from scratch. Many objects are immutable, and can only be > recreated, not modified. OK, good distinction. But the immutable ones are (always?) recreateable from code? And the rest can be made by creating a bare object "object()" and filling in its dictionary? I get errors when I try that though: >>> x = object() >>> x >>> class Foo: ... pass ... >>> x.__class__ = Foo Traceback (most recent call last): File "", line 1, in ? TypeError: __class__ must be set to new-style class, not 'classobj' object >>> I do not yet understand that error. I guess, there might also be objects that wrap external resources like sometimes handles to bitmaps where those resources could not be accessed? In Smalltalk, this is handled in part by the distinction between "new" and "basicNew", e.g.: http://lists.squeakfoundation.org/pipermail/squeak-dev/2003-May/057790.html where "new" may call initialization methods with various side effects (often just "self basicNew initialize"), but "basicNew" just gives you the object of that class without much data in it (so you can call initialize yourself or do something else). The message "basicNew" is what is used typically by Binary Object Streaming systems when objects are recreated, then they fill in the fields from what is in the file. >>So, given that a writer can inspect an instance and >>just write out all the fields in its dictionary and their values it seems >>like we can write out any object (though perhaps it may need to >>recursively write out parts of embedded objects first, and then perhaps >>patch up circular references at the end). > > > You mean pickle? Well, a pickle-like system that writes out (hopefully readable) Python program code, yes. > There's a bunch of pieces. Thanks for the elaboration on this. I need to think more on these points you raise. Still, it seems your focus here in what you outline as outstanding issues is more on reading and preserving and otherwise handling human written source code or the complexity of a large multi-module textually defined program (which is understandable for you are writing an IDE in a sense, where you want to give the user/developer help *before* the program is running) then reading and preserving objects (where source code may be just part of what is stored, and the user/developer is given help *while* the program is running). Perhaps the difference is that with an IDE you care more about how the objects are going to be created (given you are helping the user to write programs to do just that), whereas with saving and reloading an image I just care about anything that works and is marginally understandable for debugging the save/load process, expecting the coding to be done within the IDE on a fine grained basis (i.e. you are just look at one function at a time in a browser, like in Smalltalk, rather than scrolling through a file). Not to say producing clean readable Python programs as images isn't a good goal down the road for me, but clearly with an IDE it is your upfront goal. I think an innovative convergance comes if a new system with an image works well enough that people would choose using it to program over just editing long text files. --Paul Fernhout From kirby.urner at gmail.com Sun May 7 17:29:19 2006 From: kirby.urner at gmail.com (kirby urner) Date: Sun, 7 May 2006 08:29:19 -0700 Subject: [Edu-sig] History of Croquet? Message-ID: So I've only recently been exposed to screen shots of Croquet, including animated on Google video, but the whole experience is reminiscent of ActiveWorlds, which my friends and I have been exploring for years. Bonnie DeVarco (exBFI archivist) was a chief avatar for this technology, developing Virtual High School, or, as our oncologist would prefer, Virtual Cancer Conference (why fly to San Antonio to an overbooked venue, to watch PowerPoints from the cafeteria on a flat screen?). You can network virtually too, given sufficient bandwidth (which busy doctors should have). In other words, I'm seeing a lot of precedent for Croquet in the culture already, which means it likely does have a bright future. But I'm not sure everyone will syndicate under the one brand name. If t-Time is as good as people say, it oughta go the route of HTTP and promote interoperability between several alternatives in the same "virtual worlds" genre. We're not all about to jump ship, having collectively spent hundreds of man years builting nifty little cities in EduVerse or wherever (friends and I built an entire university based on Fuller's 60 degree coordination, versus the mainstream's 90 degree idea of "normal"). So let's assume peer-to-peer updating and synching becomes another basic protocol over TCP/IP, and various OSs rise to the occassion and develop a "shared world" mentality (suitable for doctor conferencing, other communications). The "NetMeeting" idea evolves to a more OpenGL style board room, complete with water pitcher and fluttering staff. The shared white board, although virtual, is persistent, and the company's legal department is actually authorized to take these peer-to-peer meetings as the real deal. That'd be a fulfillment of the Croquet prophecy I think, but we wouldn't necessarily have its characteristic branding going (e.g. that whole Alice in Wonderland theme). There's ample precedent to keep the "worlds" genre heterogenous. I personally might prefer a product from Cyan out of Spokane, just as t-Time compatible. When Alan Kay and I communicate virtually, we'd each have a selection of clients. Kirby From kirby.urner at gmail.com Sun May 7 17:53:34 2006 From: kirby.urner at gmail.com (kirby urner) Date: Sun, 7 May 2006 08:53:34 -0700 Subject: [Edu-sig] PySqueak: "Self" as the source of many ideas in Squeak In-Reply-To: <445E0D73.4010908@kurtz-fernhout.com> References: <445B02D3.7060504@kurtz-fernhout.com> <445B7BB7.70609@colorstudy.com> <445B8AF6.7050200@kurtz-fernhout.com> <445BA4F4.9020102@colorstudy.com> <445C4F7D.70104@kurtz-fernhout.com> <445D38B6.9000001@colorstudy.com> <445E0D73.4010908@kurtz-fernhout.com> Message-ID: On 5/7/06, Paul D. Fernhout wrote: > It is funny how we can all accept that learning to play a musical > instrument like the flute might take years of concentrated study to even > get a good "tone" out of it, but we expect computers to be engaging on a > minute by minute basis. Or, we just accept that learning to touch type > takes days of practice. But computer IDEs? Do they really need to be like > video games, engaging and addictive from the first quarter? This question defines a long-running theme here on edu-sig and I think you phrase it beautifully. I just don't see getting away from the intricate syntax of Latinate computer languages any time soon. They're intrinsic to the mix. However, we may have higher level simulation languages, where just dragging some ideogram or hieroglyph into a scene causes all these emergent behaviors, thanks to algorithms encoded using lexical tokens. Sometimes the knowledge domain we're hoping to model simply demands a high end animation engine running in the background. The users of this model don't participate in the source coding all that directly, and have a more graphical IDE within which to set up their energy, data, or currency flows. ESRI's use of embedded Python is a good example: to the end user, it's drag and drop, but under the hood, you're writing a Python script. The trend in modern OSs is to provide 3D geometry capability through a shared API in principle available to any hosted application. OpenGL, Direct3D, Xgl... I'm thinking that education applications in the "world" genre (like Squeak, like Uru, like ActiveWorlds) do well to take advantage of this existing machinery and not reinvent these wheels. But the glue layer, where the rubber meets the road, is still lexical in nature. I don't care how pretty your canvas is, or what kind of textured tube it came from (pneumatic, from Brazil?), it's still Python or C# or SmallTalk or some Latinate doohinky under the hood. Which isn't to say we couldn't also go with Tibetan, Cherokee, Arabic, Cyrillic or other unicode glyph language when committing lexical tokens to a parser. In principle, source code doesn't have to be Romanji. It just happens that's what most of it is so far, at this point in world history, and it's working out pretty well. And as I've said, it might be that the Kanji make more sense at a higher level anyway, when we start with the graphical simulations and need ways of counterbalancing various energies or whatever. Kirby From kirby.urner at gmail.com Mon May 8 03:58:42 2006 From: kirby.urner at gmail.com (kirby urner) Date: Sun, 7 May 2006 18:58:42 -0700 Subject: [Edu-sig] Panda3D looks cool so far... Message-ID: Just to give the flavor of 'Hello World' in the basic tutorial. Don't worry, I won't be cutting and pasting a ton of stuff. I figure if you're interested, you'll check into it yourself. But yes, it's helping me get clear on some issues. Kirby ==== # Author: Shao Zhang and Phil Saltzman # Last Updated: 4/19/2005 # # This tutorial is intended as a initial panda scripting lesson going over # display initialization, loading models, placing objects, and the scene graph. # # Step 2: After initializing panda, we define a class called World. We put # all of our code in a class to provide a convenient way to keep track of # all of the variables our project will use, and in later tutorials to handle # keyboard input. # The code contained in the __init__ method is executed when we instantiate # the class (at the end of this file). Inside __init__ we will first change # the background color of the window. We then disable the mouse-based camera # control and set the camera position. import direct.directbase.DirectStart #Initialize Panda and create a window from pandac.PandaModules import * #Contains most of Panda's modules from direct.gui.DirectGui import * #Imports Gui objects we use for putting #text on the screen import sys class World: #Our main class def __init__(self): #The initialization method caused when a #world object is created #Create some text overlayed on our screen. #We will use similar commands in all of our tutorials to create titles and #instruction guides. self.title = OnscreenText( text="Panda3D: Tutorial 1 - Solar System", style=1, fg=(1,1,1,1), pos=(0.8,-0.95), scale = .07) #Make the background color black (R=0, B=0, G=0) #instead of the default grey base.setBackgroundColor(0, 0, 0) #By default, the mouse controls the camera. Often, we disable that so that #the camera can be placed manually (if we don't do this, our placement #commands will be overridden by the mouse control) base.disableMouse() #Set the camera position (x, y, z) camera.setPos ( 0, 0, 45 ) #Set the camera orientation (heading, pitch, roll) in degrees camera.setHpr ( 0, -90, 0 ) #end class world #Now that our class is defined, we create an instance of it. #Doing so calls the __init__ method set up above w = World() #As usual - run() must be called before anything can be shown on screen run() From aharrin at luc.edu Mon May 8 04:42:33 2006 From: aharrin at luc.edu (Andrew Harrington) Date: Sun, 07 May 2006 21:42:33 -0500 Subject: [Edu-sig] Panda3D looks cool so far... In-Reply-To: References: Message-ID: <445EB019.5000307@luc.edu> In Panda, I assume an enormous amount of work is embedded in the development of models, which is invisible in code like that below. Perhaps if you use a canned cast of characters, you can avoid most of that. The latest version talks about being the first version they are trying to have work with OS X, so they are working to plug that hole. On licenses: I am not an expert on licenses. From what I heard on this list, it sounds like if we develop a major tutorial/learning system using Panda, we could not distribute it as part of the main Python distribution, but if there is an Ubuntu version, it sounds like we could distribute it separately in a reasonable fashion. It seems really stupid to have a license that says if you are in Cuba and downloading Panda, you are breaking the law. In an ideal world I would prefer to use software that does not say that. It is not clear why it should stop folks on Edu-Sig from developing a system calling for it. I am not worried about the commercial Disney history. The software seems to be given over to Carnegie Mellon without strings other than the export rules. Comments appreciated. Andy kirby urner wrote: >Just to give the flavor of 'Hello World' in the basic tutorial. Don't >worry, I won't be cutting and pasting a ton of stuff. I figure if >you're interested, you'll check into it yourself. But yes, it's >helping me get clear on some issues. > >Kirby > >==== > ># Author: Shao Zhang and Phil Saltzman ># Last Updated: 4/19/2005 ># ># This tutorial is intended as a initial panda scripting lesson going over ># display initialization, loading models, placing objects, and the scene graph. ># ># Step 2: After initializing panda, we define a class called World. We put ># all of our code in a class to provide a convenient way to keep track of ># all of the variables our project will use, and in later tutorials to handle ># keyboard input. ># The code contained in the __init__ method is executed when we instantiate ># the class (at the end of this file). Inside __init__ we will first change ># the background color of the window. We then disable the mouse-based camera ># control and set the camera position. > >import direct.directbase.DirectStart #Initialize Panda and create a window >from pandac.PandaModules import * #Contains most of Panda's modules >from direct.gui.DirectGui import * #Imports Gui objects we use for putting > #text on the screen >import sys > >class World: #Our main class > def __init__(self): #The initialization method caused when a > #world object is created > > #Create some text overlayed on our screen. > #We will use similar commands in all of our tutorials to create titles and > #instruction guides. > self.title = OnscreenText( > text="Panda3D: Tutorial 1 - Solar System", > style=1, fg=(1,1,1,1), pos=(0.8,-0.95), scale = .07) > > #Make the background color black (R=0, B=0, G=0) > #instead of the default grey > base.setBackgroundColor(0, 0, 0) > > #By default, the mouse controls the camera. Often, we disable that so that > #the camera can be placed manually (if we don't do this, our placement > #commands will be overridden by the mouse control) > base.disableMouse() > > #Set the camera position (x, y, z) > camera.setPos ( 0, 0, 45 ) > > #Set the camera orientation (heading, pitch, roll) in degrees > camera.setHpr ( 0, -90, 0 ) >#end class world > >#Now that our class is defined, we create an instance of it. >#Doing so calls the __init__ method set up above >w = World() >#As usual - run() must be called before anything can be shown on screen >run() >_______________________________________________ >Edu-sig mailing list >Edu-sig at python.org >http://mail.python.org/mailman/listinfo/edu-sig > > -- Andrew N. Harrington Computer Science Department Undergraduate Program Director Loyola University Chicago http://www.cs.luc.edu/~anh 512B Lewis Towers (office) Office Phone: 312-915-7982 Snail mail to Lewis Towers 416 Dept. Fax: 312-915-7998 820 North Michigan Avenue aharrin at luc.edu Chicago, Illinois 60611 From kirby.urner at gmail.com Mon May 8 06:07:22 2006 From: kirby.urner at gmail.com (kirby urner) Date: Sun, 7 May 2006 21:07:22 -0700 Subject: [Edu-sig] Panda3D looks cool so far... In-Reply-To: <445EB019.5000307@luc.edu> References: <445EB019.5000307@luc.edu> Message-ID: > Comments appreciated. > > Andy > I just focusing on the technology at this point, steering clear of lawyer-speak. I think it'd be good for Disney if its software had an appreciative user base wherever, including Cuba. Or is it Carnegie Mellon's now? Whatever, both/either. Carnegie Mellon is also behind VPython no? Kirby From ianb at colorstudy.com Mon May 8 09:18:05 2006 From: ianb at colorstudy.com (Ian Bicking) Date: Mon, 08 May 2006 02:18:05 -0500 Subject: [Edu-sig] PySqueak: "Self" as the source of many ideas in Squeak In-Reply-To: <445E0D73.4010908@kurtz-fernhout.com> References: <445B02D3.7060504@kurtz-fernhout.com> <445B7BB7.70609@colorstudy.com> <445B8AF6.7050200@kurtz-fernhout.com> <445BA4F4.9020102@colorstudy.com> <445C4F7D.70104@kurtz-fernhout.com> <445D38B6.9000001@colorstudy.com> <445E0D73.4010908@kurtz-fernhout.com> Message-ID: <445EF0AD.5000003@colorstudy.com> Paul D. Fernhout wrote: > Ian Bicking wrote: >> Zope went down that path with through-the-web development with the ZODB >> as the image. I think everyone agrees that didn't work. Smalltalk has >> pursued that with more vigor, but I was never comfortable with the >> image. In some ways you can read my comments as me figuring out just >> why I dislike the image model. > > Well, everyone? :-) Check out http://www.1010wins.com/ for what was, last > I heard, a major Zope site. > > Still, a lot of peopel agree with you, so there are clearly issues here. > For all I know, that group is unhappy? There's a general consensus in the Zope community that through-the-web editing and putting application code in the ZODB wasn't a good idea. So they've moved on to other means of development, mostly with files on the disk. At the same time, they've also moved away from the ideal of a web development environment accessible to beginning programmers, which was at least an early Zope goal. Though Plone is probably the exception to both of these. My impressions -- direct and indirect -- of what happens with typical projects stored in the ZODB, is that they just had all of the normal software engineering problems. But they weren't able to take advantage of all the work people were doing in other environments -- version control, Python's code layout (modules, packages, etc), and all the other tools developers use. And maybe that's the only problem (though I think there are others). On the measure of tools alone Smalltalk should be fine, as they've written their own full stack of tools, even though at the same time they pretty much isolate themselves from the mainstream of tools. I also hate the idea of extending Object, which is common in Smalltalk (and Ruby, with no image), and my distaste for that might tinge my feelings on images. Zope didn't add that, but it has its own ways of introducing that same kind of complexity that I dislike. >> I think it's important to figure out, because the image model seems very >> compelling for an education environment. > > And John also made some of those points indirectly. I think from a > "classroom" standpoint, teachers generally want to be in control of what > the student sees, at least at first, and they also have short classes ("45 > minutes) where they do not want to waste time on configuration. So, > preparing an image for kids and seeing it pop up exactly like you made it, > whatever the hardware (like Squeak can do) is a big win in a classroom > setting. Of course, I'm not big on conventional classrooms :-), but I > think images are desirable for independent or informal learning as well, > which can happen in fits and starts, where you might do something > intensely for days and then not revisit something until months later. And > it would be nice if everything was just the way you left it. Also, as a > developer of (hopefully open) educational simulations, I see the value in > being able to deploy the simulation as an image which people could then > modify to their own needs. So this is an area of overlap regardless of > educational paradigm. I think there's a lot of practical problems with that. What happens when you find a bug in the image? How do you figure out where code came from? Is it system code, teacher code, peer code, your own code? If you edit system code, you've made your image incompatible with anyone else's image, and anyone who imports your change will probably be corrupting their image. And when you have this big ball of an image, the student has to choose which line of continuity they want -- do they keep their code, or throw it all away for the next class? I'm all for making tight bundles of code with controlled environments; that's important for everyone, not just classrooms. But there's another line of control, which is how you integrate new packages into that environment, and how you extract packages, and how you update packages. A classroom should be as ready to do all of these things as professional programmers, because they actually share all the same basic needs -- fixing bugs, applying workarounds, sharing code, making code reasonably portable (if only, for instance, to allow the teacher to run it in their own environment). Software engineering tools and methodology can be hard to adopt (even for professional programmers), but there's also a lot of good ideas in there that apply much more widely than just software. So I think it's worth keeping all those processes in mind. > John Holt wrote on this when he talked about "hard fun" (also mentioned > here recently in another context I think) and how playing music, > considering the suffering involved to get good at it, could hardly be > described as "fun", but there certainly is something there for many people > that keeps it engaging as a transcendental experience (as a sense of > "flow"). Still, I think people here are right when they suggest typing at > the command line an doing text processing produces feedback that keeps > people engaged. The question is, can a graphical IDE do that, and I think > the answer with Self might usually be "yes". I think the answer with > "Squeak" is sometimes "no" though, but I have real experience with that, > and have still never used Self. :-) Programming is definitely hard fun, and like music some people are very much drawn to it and overcome all the hardness without being that bothered. That probably describes the majority of the open source community. But most people don't pursue music that seriously, even given the opportunity -- hard fun isn't very fun for most people and for any particular domain. I don't know if everyone has a hard fun that's right for them, or not. I wish everyone had something, but unfortunately I suspect that enjoying hard fun is itself something that not everyone is prepared to do. > OK, good distinction. But the immutable ones are (always?) recreateable > from code? And the rest can be made by creating a bare object "object()" > and filling in its dictionary? > > I get errors when I try that though: > >>> x = object() > >>> x > > >>> class Foo: > ... pass > ... > >>> x.__class__ = Foo > Traceback (most recent call last): > File "", line 1, in ? > TypeError: __class__ must be set to new-style class, not 'classobj' object > >>> > I do not yet understand that error. you can't turn a new-style class into an old-style class by reassigning __class__, but otherwise you can mess with that attribute pretty freely (or mess with __class__.__bases__). object() also happens to not accept attributes, though any subclass of object will. I'm not sure what the justification is for that. > I guess, there might also be objects that wrap external resources like > sometimes handles to bitmaps where those resources could not be accessed? Yes, that's very common. In general pickle-able objects can be recreated; you can do the same basic thing with the new module, like new.instance(Foo), and then update its __dict__ -- remembering that assigning to attributes might not work, since those attributes might be properties that expect the __init__ to have been called. The object may register itself or do other things in __init__ as well, so it's really hard to be sure you are doing the right thing. Really, it's all the same issues pickle has, and pickle also has some special methods so that most objects can be made pickleable. Some things like open file objects just can't be pickled at all, ever -- though often you can make a pickleable wrapper that fulfills some more abstract purpose, and use pickle's hooks to keep from trying to pickle that objects entire __dict__ (which probably contains the unpickleable file object). >> There's a bunch of pieces. > > Thanks for the elaboration on this. I need to think more on these points > you raise. > > Still, it seems your focus here in what you outline as outstanding issues > is more on reading and preserving and otherwise handling human written > source code or the complexity of a large multi-module textually defined > program (which is understandable for you are writing an IDE in a sense, > where you want to give the user/developer help *before* the program is > running) then reading and preserving objects (where source code may be > just part of what is stored, and the user/developer is given help *while* > the program is running). Perhaps the difference is that with an IDE you > care more about how the objects are going to be created (given you are > helping the user to write programs to do just that), whereas with saving > and reloading an image I just care about anything that works and is > marginally understandable for debugging the save/load process, expecting > the coding to be done within the IDE on a fine grained basis (i.e. you are > just look at one function at a time in a browser, like in Smalltalk, > rather than scrolling through a file). Not to say producing clean readable > Python programs as images isn't a good goal down the road for me, but > clearly with an IDE it is your upfront goal. I think an innovative > convergance comes if a new system with an image works well enough that > people would choose using it to program over just editing long text files. In part I want to avoid a disconnect between the two styles of development. This was another problem with Zope -- people would start with the image/ZODB development, and then it was a really big leap to get to the file-based development. So there was two classes of Zope users, and they didn't always understand each other. Also, I don't want to have to recreate version control tools, or Python's module system, or the ability to share code freely, or any of that stuff. I think a good way to avoid any problems with these tools and processes is to just stick to conventional program representations. -- Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org From francois.schnell at gmail.com Mon May 8 13:11:54 2006 From: francois.schnell at gmail.com (francois schnell) Date: Mon, 8 May 2006 13:11:54 +0200 Subject: [Edu-sig] KPL v 1.1 seems to go "Open Source" Message-ID: <13a83ca10605080411x559a312bsa0f2911b613570f3@mail.gmail.com> I've never tried KPL "Kids Programming Language" (Windows, .Net based) but I just saw they're moving to "open source" for v 1.1 (which eventually/maybe open some possibilities for Linux/Mono/Python ports). seen here: http://digg.com/software/Kids_Programming_Language_(KPL)_going_open-source and: http://p211.ezboard.com/fkplfrm20.showMessage?topicID=1.topic francois -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20060508/56adf4d7/attachment.html From delza at livingcode.org Mon May 8 18:32:49 2006 From: delza at livingcode.org (Dethe Elza) Date: Mon, 8 May 2006 09:32:49 -0700 Subject: [Edu-sig] Errors in Wikipedia entry for IronPython? In-Reply-To: References: Message-ID: <24d517dd0605080932p1379eb7ei1804f6566538ca4d@mail.gmail.com> On 5/6/06, kirby urner wrote: > I have a problem with this example code: > > from BookService import BookDictionary > > booksWrittenByBookerPrizeWinners = [] > for book in BookDictionary.GetAllBooks: > if "Booker Prize" in book.Author.MajorAwards: > booksWrittenByBookerPrizeWinners.append(book.Title) > booksWrittenByBookerPrizeWinners > > First, the variable names seem intentionally ugly, but I'm not going > to worry about that. There is a style of programming where you spell out what you're doing in graphic detail, as opposed to just declaring var x,y,z; def foo(x,y): return z style of minimalist programming. Most Python code is somewhere in between, but when using an external system (dotNet in your example, PyObjC in my experience), it makes sense to have the python code reflect the style of the main library/framework that you're using (or wrap it out of sight altogether, the way PyGUI tries to do). What really bugs me is > BookDictionary.GetAllBooks without making it callable. The prefixing > verb Get would imply a function, and Python distinguishes itself from > Ruby (per Martelli) by making a sharp distinction between a function > *named* and a function *called*. In Java, rather than properties, they have the JavaBeans naming convention. According to this convention, getters are named getFoo() -> foo, and setters are named setFoo(foo) -> void. In most of the dotNet code I've seen, you can take Java (or SVG, or whatever system they're imitating this month) and make it initCap (getFoo() becomes GetFoo()). Since Jython treats the JavaBeans calling conventions as properties, I assume IronPython is doing something similar. Although in that case, you should be able to just write AllBooks rather than GetAllBooks (although both ways might work). > Perhaps its just an unfortunate naming issue, i.e. GetAllBooks is > really to be thought of as an iterable, not a function call. Under > the hood, there might be some property, i.e. if it has to consult a > database (whatever BookService does). But in that case, I'd really > prefer a function with no arguments, a callable in other words. > > Anyway, as you can see, I'm unhappy with this code. > > Plus there's a clear typo in the next sentence: > > "In this case, assume that the .NET framework implements a class, > BookDictionary, in a module called BookService, and publishes an > interface into which IronPython scripts can be sent and exectuted." > > I've edited Wikipedia before, but hesitate to dive in on this one > without more seasoning (comments?). I think you should freely change the obvious typo, but not the code unless you've tried to run it and found it does not actually work. I don't have IronPython, or any intention to install or run it, so take anything I say about it with a large grain of salt. --Dethe > > Kirby > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > From delza at livingcode.org Mon May 8 19:00:21 2006 From: delza at livingcode.org (Dethe Elza) Date: Mon, 8 May 2006 10:00:21 -0700 Subject: [Edu-sig] PySqueak: more on the cultural divide among paradigms In-Reply-To: <200605061025.02196.john.zelle@wartburg.edu> References: <445B8491.9070802@kurtz-fernhout.com> <24d517dd0605051554j11622b10wcdfd1e92b4bbacb5@mail.gmail.com> <200605061025.02196.john.zelle@wartburg.edu> Message-ID: <24d517dd0605081000h759842e1n37c83a9c69ba2bd9@mail.gmail.com> [snip] John Zelle wrote: > I've been thinking about just this sort of project. That's a relief, sometimes I think I'm the only one thinking in this direction. > My hunch is that a Vpython > in Python is now very doable using PyOpenGL. By building on OpenGL, most of > the heavy graphics lifting can be done on the graphics card (even cheap ones > are ridiculously fast these days). The OpenGL API is now standardized and > stable for development, as long as one sticks to basic features for which > hardware acceleration can be taken as a given. > > But OpenGL is not a modeling API, it's purely for drawing things. We need a > higher-level standardized scene graph layer (ala VPython). This combination > would make the entire graphics stack down to hardware Python based. VPython > as it stands is very nice, but it is not extendable in Python. Want a more > realistic shading model? No can do. Texture mapping? Out of luck. > Stereo-modes? (well OK, but I had to do that in C++ ;-). It might be that > something like the PyOpenGL Context code base could be used as a starting > point. Yes, these are exactly the issues I run into with VPython (that, and having to run it on OS X in linux-emulation mode). > Along-side the modeling layer we need a good OpenGL-based gui toolkit as well. > You really can't build a decent GUI in something like VPython. It would be > nice if solid, good-looking applications could be built entirely on Python > w/o having to introduce some other C/C++ dependencies. Relying only on > OpenGL would give us a truly portable GUI kit (except for a very thin layer > that glues it to the underlying windowing system ala GLUT). It could have a > consistent, though not necessarily native look and feel anywhere OpenGL runs. > I'm willing to give up native look and feel provided the toolkit looks great > and has really snappy performance. Another approach would be to make the GUI > themeable, so folks could easily implement themes to mimick standard native > widget sets. Basing on OpenGL should provide these abilities. The entire > X-library has now been impelemented on OpenGL, there's no reason in principle > a decent OO gui framework couldn't also be built there (and there are already > some candidates out there to use as models). By making VPython play well with other OpenGL-based systems we should be able to get this "for free" or nearly so. For one thing, The 2D system Cairo has an OpenGL backend called Glitz, and folks are definitely using Cairo to build GUIs. > > I know I'd love to have a 3D environment that was both easy to use, > > and extensible. > > Exactly. I agree that Vpython in Python would be a great start. Yeah! > To me, it seems that a 2D/3D persistent scene-graph API paired with a GUI > toolkit, both based on PyOpenGL is the obvious first step toward this goal. > Alone, it would not really be very Squeak-like, but a Squeaky IDE needs the > ability to describe a persisitent view (2D or 3D) as a basic starting point. > On top of that foundation others can build the ultimate constructivist > educational platform...or just some neat, useable 2D and 3D applications. > Others could work on extending and improving the whole shebang without having > to know any C or C++. > > The only question in my mind is how do we get started in making this vision a > reality? I'd love to dive in and start working on it myself, but > realistically, I've already got a lot of committments (writing is *$&% hard > work :-). Where do we go from here? Ideas Dethe? I have taken a stab at reimplementing VPython in PyOpenGL, but ran out of motivation. I have some outstanding time committments for my hobby-coding time for the next month or so, but would be willing to take this up again. Certainly the OpenGL context work would make a good starting point, at least for tips and examples, even if the final result was not built on that. There is also an open-source X3D engine which might be useful for an example state machine. One of the reasons I periodically get excited about Python bindings to 3D engines like Blender, Ogre, Panda3d, etc., is that I hope that they will provide a better basis to build a new, inclusive VPython on than raw OpenGL, but I think that is just wishful thinking and I should roll up my sleeves and Just Do It. > By the way, how is the non-Fink port of Vpython for OSX going? We could really > use that right now. My Mac students don't want to mess with Fink just to do a > few Vpython projects. Their build system defeated me. I finally gave in and installed the Fink version, which pulls in Gnome, among other things (632 MB to access the OpenGL that is *built in* to OS X). It took many hours to install, requires X, and brings my system to a crawl when I use it. I think my time might be better used porting it to Python than trying to fix their autoconf-and-Boost madness. As you say, simplicity is what makes VPython shine, and the system doesn't actually do all that much. It's a shame that the simplicity ends when you try to build it. --Dethe > > -- > John M. Zelle, Ph.D. Wartburg College > Professor of Computer Science Waverly, IA > john.zelle at wartburg.edu (319) 352-8360 > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > From lac at strakt.com Mon May 8 19:23:34 2006 From: lac at strakt.com (Laura Creighton) Date: Mon, 08 May 2006 19:23:34 +0200 Subject: [Edu-sig] Petty Issue In-Reply-To: Message from Chuck Allison of "Fri, 05 May 2006 12:14:42 MDT." <599704612.20060505121442@freshsources.com> References: <599704612.20060505121442@freshsources.com> Message-ID: <200605081723.k48HNYXL012323@theraft.strakt.com> Fredrik Lundh's introduction to the python standard library comes with a CD. http://www.oreilly.com/catalog/pythonsl/ It is a little dated, being from 2001, but since you are trying to get around a rule .... Laura In a message of Fri, 05 May 2006 12:14:42 MDT, Chuck Allison writes: >Hello edu-sig, > > I'm really sorry to waste your time, but this is the only place I > know to go to get a quick answer. > > I have mentioned here before that I am teaching intermediate Python > at Symantec in June. Since they merged with another company last > year, they have some new red tape that disallows one-person > companies like myself to do business with them (it seems I don't > have enough liability insurance - true - I have none!). To get > around the system, I have to, among other things, "sell" them a > Python book with a CD in it. (Don't ask me why - this is bean > counting mentality at its best). Anyway, I can't find a worthy book > with a CD. Most are out of date or too simple. (I wish Martelli's > books had CDs!) Even John Zelle's excellent book, with has an > accompanying CD, is too basic for our needs (it's an ideal CS1 book, > of course). So: do you know of a book with a CD that is > intermediate, or... do you know of a stand-alone CD product that > covers some meaty Python? > > Thanks, and again, sorry to interrupt more profitable discussion. > >-- >Best regards, > -- Chuck Allison > > >_______________________________________________ >Edu-sig mailing list >Edu-sig at python.org >http://mail.python.org/mailman/listinfo/edu-sig From kirby.urner at gmail.com Mon May 8 19:26:58 2006 From: kirby.urner at gmail.com (kirby urner) Date: Mon, 8 May 2006 10:26:58 -0700 Subject: [Edu-sig] Errors in Wikipedia entry for IronPython? In-Reply-To: <24d517dd0605080932p1379eb7ei1804f6566538ca4d@mail.gmail.com> References: <24d517dd0605080932p1379eb7ei1804f6566538ca4d@mail.gmail.com> Message-ID: > In Java, rather than properties, they have the JavaBeans naming > convention. According to this convention, getters are named getFoo() > -> foo, and setters are named setFoo(foo) -> void. In most of the > dotNet code I've seen, you can take Java (or SVG, or whatever system > they're imitating this month) and make it initCap (getFoo() becomes > GetFoo()). Since Jython treats the JavaBeans calling conventions as > properties, I assume IronPython is doing something similar. Although > in that case, you should be able to just write AllBooks rather than > GetAllBooks (although both ways might work). Yes, I'm somewhat familiar with JavaBeans. It wasn't the naming conventions that bothered me so much, as using Get... but not making it a callable. I gather some more feedback. Not a high priority. > I think you should freely change the obvious typo, but not the code > unless you've tried to run it and found it does not actually work. I > don't have IronPython, or any intention to install or run it, so take > anything I say about it with a large grain of salt. > > --Dethe OK. Kirby From delza at livingcode.org Mon May 8 19:47:14 2006 From: delza at livingcode.org (Dethe Elza) Date: Mon, 8 May 2006 10:47:14 -0700 Subject: [Edu-sig] PySqueak: "Self" as the source of many ideas in Squeak In-Reply-To: <445C45B4.9060503@kurtz-fernhout.com> References: <445B02D3.7060504@kurtz-fernhout.com> <445B7BB7.70609@colorstudy.com> <445C45B4.9060503@kurtz-fernhout.com> Message-ID: <24d517dd0605081047p28225e10j548032e573ea7551@mail.gmail.com> On 5/5/06, Paul D. Fernhout wrote: > Of course, you probably don't have a Self-like environment for Javascript. > :-) Or is there one? I've never done much with JavaScript. Javascript is a prototype-based language deriving directly from Self. Emulating inheritance-type OO is possible, but kind of a hack, mainly done for folks who are new to prototype-based languages. > Designing programming systems is so easy when you stop caring about > performance (at least in the short term). :-) But the advice I was given > long ago is, slightly updated, is: by the time you get it debugged and > anyone has noticed it, computers will be fast enough to run it. :-) That hasn't worked well for Squeak, in my experience. Every time I get a faster computer I try it out, and it's still too slow to use. Also, I think one big reason people are leery of putting all their methods and changes on the root object (or even allowing key objects to be modified) is that introspecting objects to find out what messages they can be expected to respond to is a crucial learning path. That is why Python doesn't let you extend object, string, or int, for example, in order to keep the system predictable and reduce the impact of running dir(string) to something a person can understand. If you did that on a javax.swing.JButton (and Jython implemented dir() so that it showed all available methods, which it doesn't) then you would be overwhelmed with hundreds of options, many of which are implementation details of AWT or Swing, or other widgets, and very few of which are useful to the common expectations and needs of using a simple button widget. So, performance is part of it, but comprehensibility (is that a word?) is the more important part. And yes, I realize that prototype-based languages don't have to be like that, but when you can add methods to root objects, the tendency is to do so, and it can make things very hard to maintain. I know Ruby allows this, but haven't had enough experience with Ruby to know if it's a problem. In Javascript, it definitely is a problem, with libraries like Prototype encouraging "let's stick every method on the root object" mentality and cluttering the namespace. In Objective-C there is a nice middle ground, where you can have a new object layer that adds methods to existing classes when it is imported. So you can add things where they feel *right,* but you're not encouraged to do so willy-nilly. That works for me. > > I'm not really sure how to fit HyperCard into this -- I don't have a > > strong feel for what it really means. I suppose one aspect is that the > > source code is not at the core; instead the card stack is (or whatever > > content-centric metaphor you use), and code is attached there. Ad hoc > > structured code doesn't work that well with a class... you get something > > like: I think Hypercard fits into the conversation because (like in Morphic (Self or Squeak)), you can access the script behind every widget at runtime, as if each widget has its own "view source" window, except editable. Which would be cool for Python to adopt, I think. > But I kind of see HyperCard as more like just one set of widgets in a > Morphic style interface. Yes, very similar ideas. Also the game The Incredible Machine, with it's halo of options around each object (though not editable). --Dethe From kirby.urner at gmail.com Mon May 8 20:19:44 2006 From: kirby.urner at gmail.com (kirby urner) Date: Mon, 8 May 2006 11:19:44 -0700 Subject: [Edu-sig] More on Panda3D Message-ID: So I think the first thing will be to write a new subclass of writer, as I've already done for VRML, VRML2, EIG, POV-Ray, and Live3D.[1] There's already an Egg API that will allow me to avoid low-level bricking in with strings (no direct eggfile.write('stuff')). Here's what it looks like (from the documentation [2]): def makeWedge(angleDegrees = 360, numSteps = 16): data = EggData() vp = EggVertexPool('fan') data.addChild(vp) poly = EggPolygon() data.addChild(poly) v = EggVertex() v.setPos(Point3D(0, 0, 0)) poly.addVertex(vp.addVertex(v)) angleRadians = deg2Rad(angleDegrees) for i in range(numSteps + 1): a = angleRadians * i / numSteps y = math.sin(a) x = math.cos(a) v = EggVertex() v.setPos(Point3D(x, 0, y)) poly.addVertex(vp.addVertex(v)) # To write the egg file to disk, use this: data.writeEgg(Filename("wedge.egg")) # To load the egg file and render it immediately, use this: node = loadEggData(data) return NodePath(node) So I'll just suck up a Polyhedron from my rbf.py, spoon feed the vertices and polygons via the Egg API, then load the egg in a Panda scenegraph for display. I should be getting my initial results shortly. I'll publish some source code. Query: could we reimplement the whole Elastic Interval Geometry thing inside of Panda3D. At this point, I see no reason why not. If we treated the intervals as changing-size Bones at runtime, I bet we could get some interesting Creatures. I recently sent a heads-up to Gerald (originator of EIG, inspired by Kenneth Snelson [3]), regarding my appreciative mention of his work a few times in my LKL talk.[4] Kirby [1] http://www.4dsolutions.net/ocn/python/povray.html (example POV writer) [2] http://panda3d.etc.cmu.edu/wiki/index.php/Writing_3D_Models_out_to_Disk [3] Kenneth Snelson: http://www.kennethsnelson.net/ http://www.grunch.net/snelson/ http://worldgame.blogspot.com/2006/05/barrel-tower.html [4] http://bfi.org/pythonicmathematics From tom.hoffman at gmail.com Mon May 8 20:48:50 2006 From: tom.hoffman at gmail.com (Tom Hoffman) Date: Mon, 8 May 2006 14:48:50 -0400 Subject: [Edu-sig] More on Panda3D In-Reply-To: References: Message-ID: <92de6c880605081148n5ca7366ck9e0d833bafebe2b6@mail.gmail.com> Hi Kirby, Have you also looked at Soya? I don't think it has come up in this conversation. http://home.gna.org/oomadness/en/soya/index.html Soya 3D is a very high level 3D engine for Python. Soya aims at being to 3D what Python is to programming : fast to learn, easy to use, while keeping good performances ! Our goal is to propose a complete architecture to realise Free (GPL) games with professional quality entierely in Python. It seems to cover similar territory to Panda3D, but it is more of a grassroots community creation. I haven't gotten into either far enough to really say which one is better, although Soya's definitely the tougher install. --Tom On 5/8/06, kirby urner wrote: > So I think the first thing will be to write a new subclass of writer, > as I've already done for VRML, VRML2, EIG, POV-Ray, and Live3D.[1] > > There's already an Egg API that will allow me to avoid low-level > bricking in with strings (no direct eggfile.write('stuff')). Here's > what it looks like (from the documentation [2]): > > def makeWedge(angleDegrees = 360, numSteps = 16): > data = EggData() > > vp = EggVertexPool('fan') > data.addChild(vp) > > poly = EggPolygon() > data.addChild(poly) > > v = EggVertex() > v.setPos(Point3D(0, 0, 0)) > poly.addVertex(vp.addVertex(v)) > > angleRadians = deg2Rad(angleDegrees) > > for i in range(numSteps + 1): > a = angleRadians * i / numSteps > y = math.sin(a) > x = math.cos(a) > > v = EggVertex() > v.setPos(Point3D(x, 0, y)) > poly.addVertex(vp.addVertex(v)) > > # To write the egg file to disk, use this: > data.writeEgg(Filename("wedge.egg")) > > # To load the egg file and render it immediately, use this: > node = loadEggData(data) > return NodePath(node) > > So I'll just suck up a Polyhedron from my rbf.py, spoon feed the > vertices and polygons via the Egg API, then load the egg in a Panda > scenegraph for display. > > I should be getting my initial results shortly. I'll publish some source code. > > Query: could we reimplement the whole Elastic Interval Geometry thing > inside of Panda3D. At this point, I see no reason why not. If we > treated the intervals as changing-size Bones at runtime, I bet we > could get some interesting Creatures. > > I recently sent a heads-up to Gerald (originator of EIG, inspired by > Kenneth Snelson [3]), regarding my appreciative mention of his work a > few times in my LKL talk.[4] > > Kirby > > [1] http://www.4dsolutions.net/ocn/python/povray.html (example POV writer) > > [2] http://panda3d.etc.cmu.edu/wiki/index.php/Writing_3D_Models_out_to_Disk > > [3] Kenneth Snelson: > http://www.kennethsnelson.net/ > http://www.grunch.net/snelson/ > http://worldgame.blogspot.com/2006/05/barrel-tower.html > > [4] http://bfi.org/pythonicmathematics > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > From kirby.urner at gmail.com Mon May 8 21:28:28 2006 From: kirby.urner at gmail.com (kirby urner) Date: Mon, 8 May 2006 12:28:28 -0700 Subject: [Edu-sig] More on Panda3D In-Reply-To: <92de6c880605081148n5ca7366ck9e0d833bafebe2b6@mail.gmail.com> References: <92de6c880605081148n5ca7366ck9e0d833bafebe2b6@mail.gmail.com> Message-ID: On 5/8/06, Tom Hoffman wrote: > Hi Kirby, > > Have you also looked at Soya? I don't think it has come up in this > conversation. > > http://home.gna.org/oomadness/en/soya/index.html I believe this came up on the LKL tape (Quicktime streaming) but not here, you're right. I'll bone up on Soya too. > It seems to cover similar territory to Panda3D, but it is more of a > grassroots community creation. I haven't gotten into either far > enough to really say which one is better, although Soya's definitely > the tougher install. > > --Tom I'm not biased against company or university branding on open source products per se i.e. the Ximian, Disney and/or Carnegie Mellon logos aren't troublesome in and of themselves. But like any investor, I like to get a sense of the health of the developer community, whatever the superficials. It being open source is a positive sign but is not in and of itself enough to reassure. Frequent improvements happening is more what we look for. So far, nothing bothers me about Panda. But now I've got high hopes for Soya too, so thanks for the pointer. Kirby From delza at livingcode.org Mon May 8 22:25:08 2006 From: delza at livingcode.org (Dethe Elza) Date: Mon, 8 May 2006 13:25:08 -0700 Subject: [Edu-sig] More on Panda3D In-Reply-To: <92de6c880605081148n5ca7366ck9e0d833bafebe2b6@mail.gmail.com> References: <92de6c880605081148n5ca7366ck9e0d833bafebe2b6@mail.gmail.com> Message-ID: <24d517dd0605081325v519ecd53n1b13987e724ac512@mail.gmail.com> On 5/8/06, Tom Hoffman wrote: > Hi Kirby, > > Have you also looked at Soya? I don't think it has come up in this > conversation. > > http://home.gna.org/oomadness/en/soya/index.html Soya is one of those projects that looks intriguing, but I get put off by the large numbers of dependencies involved. It is often hard enough to figure out where to begin with a big library, just from a coding perspective, without having to find the right versions of the right libraries, and resolve all the issues getting them compiled and working together. If there were binary downloads (or easy_install eggs) for the common platforms, I'm sure it would get more traction. >From reading the project pages, I'm not even sure if Soya runs on OS X, which makes me even more reluctant to spend my time trying to put all the pieces together. > Soya 3D is a very high level 3D engine for Python. Soya aims at being > to 3D what Python is to programming : fast to learn, easy to use, > while keeping good performances ! Our goal is to propose a complete > architecture to realise Free (GPL) games with professional quality > entierely in Python. This all sounds great. Unfortunately the documentation link is broken, which makes it hard to evaluate the completeness/complexity tradeoffs of Soya. If there were an easy way to get started (download and docs) I would happily explore, and possibly contribute. > It seems to cover similar territory to Panda3D, but it is more of a > grassroots community creation. I haven't gotten into either far > enough to really say which one is better, although Soya's definitely > the tougher install. Well, if Soya is known to work with OS X, that would make it the easier install for me, since Panda3D does not yet run on OS X (it's being worked on, but slowly). > --Tom --Dethe From kirby.urner at gmail.com Tue May 9 18:33:05 2006 From: kirby.urner at gmail.com (kirby urner) Date: Tue, 9 May 2006 09:33:05 -0700 Subject: [Edu-sig] More on Panda3D In-Reply-To: References: Message-ID: On 5/8/06, kirby urner wrote: > So I think the first thing will be to write a new subclass of writer, > as I've already done for VRML, VRML2, EIG, POV-Ray, and Live3D.[1] > Making progress on this, but of more generic interest to new users on WinXP would be getting something like this to work: IDLE 1.1.2 >>> import direct.directbase.DirectStart DirectStart: Starting the game. Warning: DirectNotify: category 'Interval' already exists >>> run() Disregarding the Warning, this is a positive state of affairs. Here we are in old familiar IDLE, yet able to import and dynamically interact with the Panda3D classes. Of course the exact same setup is what's implemented in Linux (indeed, Tk-based PMW = Python Megawidgets are integral to the end user interface itself), but in Windows you might run into some weird path issues, owing to the fact that you already have Python installed, yet Panda3D brings along its own (the "right version"). Like this: D:\Panda3D-1.2.2\bin\lib>cd.. D:\Panda3D-1.2.2\bin>ppython .\lib\idlelib\idle.py Traceback (most recent call last): File ".\lib\idlelib\idle.py", line 21, in ? idlelib.PyShell.main() File "D:\Panda3D-1.2.2\bin\lib\idlelib\PyShell.py", line 1350, in main root = Tk(className="Idle") File "D:\Panda3D-1.2.2\bin\lib\lib-tk\Tkinter.py", line 1569, in __init__ self.tk = _tkinter.create(screenName, baseName, className, interactive, wantobjects, useTk, sync, use) _tkinter.TclError: Can't find a usable init.tcl in the following directories: D:/Panda3D-1.2.2/bin/lib/tcl8.4 D:/Panda3D-1.2.2/lib/tcl8.4 D:/lib/tcl8.4 D:/Panda3D-1.2.2/library D:/library D:/tcl8.4.7/library This probably means that Tcl wasn't installed properly. Here's my suggestion: copy your tk8.4 and tcl8.4 folders/contents from under a normal python2.4 install from python.org, and put them in /Panda3D-1.2.2/bin/lib/ Works for me, algthough I still get cmd window screen garbage -- which is fine, I'm used to that on Linux as well (I run GNOME and KDE systems in partitions of two other computers, plus am shopping for a couple dedicated laptops for U- and Edu- buntu work). Kirby From dblank at brynmawr.edu Tue May 9 23:03:13 2006 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Tue, 09 May 2006 17:03:13 -0400 Subject: [Edu-sig] Errors in Wikipedia entry for IronPython? In-Reply-To: <24d517dd0605080932p1379eb7ei1804f6566538ca4d@mail.gmail.com> References: <24d517dd0605080932p1379eb7ei1804f6566538ca4d@mail.gmail.com> Message-ID: <1147208593.13590.82.camel@mightymouse.brynmawr.edu> On Mon, 2006-05-08 at 09:32 -0700, Dethe Elza wrote: > I > don't have IronPython, or any intention to install or run it, so take > anything I say about it with a large grain of salt. Wondering why you won't touch IronPython? It looks like it has the potential to span what currently takes C/C++ plus SWIG plus Python, but puts it into one framework, and may run more quickly than the other. It also runs under Mono on many OSes and .NET on Windows. Is it because it has touched the hands of Microsoft? It is "open source" (in as far as the shared source license looks open), and Microsoft has (so far) been very faithful to replicating CPython's behavior. If it had generic cross-platform graphics, or were embedded in a browser, then it sounds like it might be just the right Python for doing many educational projects mentioned on this list in the last few weeks. -Doug > --Dethe -- Douglas S. Blank Computer Science Assistant Professor Bryn Mawr College (610)526-6501 http://cs.brynmawr.edu/~dblank From delza at livingcode.org Tue May 9 23:50:30 2006 From: delza at livingcode.org (Dethe Elza) Date: Tue, 9 May 2006 14:50:30 -0700 Subject: [Edu-sig] Errors in Wikipedia entry for IronPython? In-Reply-To: <1147208593.13590.82.camel@mightymouse.brynmawr.edu> References: <24d517dd0605080932p1379eb7ei1804f6566538ca4d@mail.gmail.com> <1147208593.13590.82.camel@mightymouse.brynmawr.edu> Message-ID: <24d517dd0605091450h1e62f93j8a07fb59fd22e8d8@mail.gmail.com> > Wondering why you won't touch IronPython? It looks like it has the > potential to span what currently takes C/C++ plus SWIG plus Python, but > puts it into one framework, and may run more quickly than the other. It > also runs under Mono on many OSes and .NET on Windows. Is it because it > has touched the hands of Microsoft? It is "open source" (in as far as > the shared source license looks open), and Microsoft has (so far) been > very faithful to replicating CPython's behavior. If it had generic > cross-platform graphics, or were embedded in a browser, then it sounds > like it might be just the right Python for doing many educational > projects mentioned on this list in the last few weeks. CPython does what I need. Mono/dotNet is the answer to problems I don't have. My main platform is OS X, and PyObjC bridges quite nicely between Cocoa and CPython. It's not just the "hand of Microsoft," though I admit I don't particularly like doing business with unrepentant convicted monopolists, but I don't have much use for Jython most of the time either. When I have to use Java for something, Jython is the ticket, but that happens less and less these days. Using a huge VM designed for statically compiled languages to run dynamic languages on is a neat trick, it's cool that it can be done, but it's not something I actually see much point in using over CPython's own VM. I'm not trying to start a religious war or make (much) of a statement here, just saying it's not for me. --Dethe > > -Doug > > > --Dethe > > -- > Douglas S. Blank Computer Science > Assistant Professor Bryn Mawr College > (610)526-6501 http://cs.brynmawr.edu/~dblank > > > From kirby.urner at gmail.com Wed May 10 03:17:16 2006 From: kirby.urner at gmail.com (kirby urner) Date: Tue, 9 May 2006 18:17:16 -0700 Subject: [Edu-sig] Errors in Wikipedia entry for IronPython? In-Reply-To: <24d517dd0605091450h1e62f93j8a07fb59fd22e8d8@mail.gmail.com> References: <24d517dd0605080932p1379eb7ei1804f6566538ca4d@mail.gmail.com> <1147208593.13590.82.camel@mightymouse.brynmawr.edu> <24d517dd0605091450h1e62f93j8a07fb59fd22e8d8@mail.gmail.com> Message-ID: On 5/9/06, Dethe Elza wrote: > days. Using a huge VM designed for statically compiled languages to > run dynamic languages on is a neat trick, it's cool that it can be > done, but it's not something I actually see much point in using over > CPython's own VM. In the case of the CLR, I think it *was* designed with dynamic languages in mind, but Jim Hugunin thought it wouldn't prove out, and Python would make an excellent case study showing why. To his surprise, the CLR proved worthy, and IronPython was born. I assume Mono could run on OS X. http://www.mono-project.com/Mono:OSX However, to be realistic, the current almost-out-of-beta IronPython requires .NET 2.0. I'm pretty sure it doesn't run on the most current production version of Mono yet, although I could be wrong and would be happy to be corrected. http://www.mono-project.com/Mono_Project_Roadmap I could try it myself, but am steeped in Panda3D for now. I feel pretty confidant that Mono and .NET will be a cross-platform solution favored by many Python developers, including those looking for control over the kinds of OpenGL-type applications we've been brainstorming here on edu-sig. Kirby From kirby.urner at gmail.com Wed May 10 03:25:02 2006 From: kirby.urner at gmail.com (kirby urner) Date: Tue, 9 May 2006 18:25:02 -0700 Subject: [Edu-sig] More on Panda3D In-Reply-To: References: Message-ID: So as not to clutter up the lists with too much Panda3D stuff, I'll just share a pointer to my blog. Anyone interested in where I'm going with this thread can read up on that here: http://worldgame.blogspot.com/2006/05/panda3d.html Thanks to edu-sig posters especially for giving me lots to think about. Kirby From dblank at brynmawr.edu Wed May 10 03:41:42 2006 From: dblank at brynmawr.edu (dblank at brynmawr.edu) Date: Tue, 9 May 2006 21:41:42 -0400 (EDT) Subject: [Edu-sig] Errors in Wikipedia entry for IronPython? In-Reply-To: References: <24d517dd0605080932p1379eb7ei1804f6566538ca4d@mail.gmail.com> <1147208593.13590.82.camel@mightymouse.brynmawr.edu> <24d517dd0605091450h1e62f93j8a07fb59fd22e8d8@mail.gmail.com> Message-ID: <34536.68.34.179.248.1147225302.squirrel@webmail.brynmawr.edu> Kirby spake: > However, to be realistic, the current almost-out-of-beta IronPython > requires .NET 2.0. I'm pretty sure it doesn't run on the most current > production version of Mono yet, although I could be wrong and would be > happy to be corrected. IronPython does run under Mono, at least basically, and is getting better every week. Of course, both Mono and IronPython are changing rapidly, but I think later this year they will both be usable together. > http://www.mono-project.com/Mono_Project_Roadmap > > I could try it myself, but am steeped in Panda3D for now. > > I feel pretty confidant that Mono and .NET will be a cross-platform > solution favored by many Python developers, including those looking > for control over the kinds of OpenGL-type applications we've been > brainstorming here on edu-sig. I will be beginning such a project soon, and will keep you abreast of the pros, cons, gotchas, and goodies. -Doug > Kirby From kirby.urner at gmail.com Wed May 10 21:36:12 2006 From: kirby.urner at gmail.com (kirby urner) Date: Wed, 10 May 2006 12:36:12 -0700 Subject: [Edu-sig] Panda3D + Blender on Edubuntu Message-ID: Per this blog post, I've got Panda3D running on Edubuntu: http://controlroom.blogspot.com/2006/05/edubuntu.html Blender was already a part of the default installation. However, on this Compaq Deskpro, I'm noticing a lot of graphical anomolies around menu highlighting and other controls. Blender, you may recall, distinguishes itself by defining all controlling widgets (of which it has many) internally to the OpenGL interface, i.e. there's no sense of a frame different from the canvas (Panda3D by contrast, uses the Tk-based Python Megawidgets classes for controls). It'd be useful to have Blender stay in the picture, from a Panda-user viewpoint, as from what I've gleaned from the docs, Blender is one of the best platforms for creating new action figures for Panda. There's a file format they have in common, given an included conversion utility. Kirby From francois.schnell at gmail.com Wed May 10 22:50:53 2006 From: francois.schnell at gmail.com (francois schnell) Date: Wed, 10 May 2006 22:50:53 +0200 Subject: [Edu-sig] Panda3D + Blender on Edubuntu In-Reply-To: References: Message-ID: <13a83ca10605101350y5469d3e8q92c0179460ef3451@mail.gmail.com> Nice, I need to give Panda 3D a try on my Breezy. Also for those who haven't checked lately Blender web site, the "Open Source" Orange Project (short animation released under Creative Commons -BY) looks nice: http://orange.blender.org/ Kirby (???? ), your incredible, you're everywhere ;) http://en.wikipedia.org/wiki/Kirby_(Nintendo) francois On 10/05/06, kirby urner wrote: > > Per this blog post, I've got Panda3D running on Edubuntu: > http://controlroom.blogspot.com/2006/05/edubuntu.html > > Blender was already a part of the default installation. However, on > this Compaq Deskpro, I'm noticing a lot of graphical anomolies around > menu highlighting and other controls. > > Blender, you may recall, distinguishes itself by defining all > controlling widgets (of which it has many) internally to the OpenGL > interface, i.e. there's no sense of a frame different from the canvas > (Panda3D by contrast, uses the Tk-based Python Megawidgets classes for > controls). > > It'd be useful to have Blender stay in the picture, from a Panda-user > viewpoint, as from what I've gleaned from the docs, Blender is one of > the best platforms for creating new action figures for Panda. There's > a file format they have in common, given an included conversion > utility. > > Kirby > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20060510/1d829a05/attachment.html From kirby.urner at gmail.com Thu May 11 00:04:09 2006 From: kirby.urner at gmail.com (kirby urner) Date: Wed, 10 May 2006 15:04:09 -0700 Subject: [Edu-sig] Panda3D + Blender on Edubuntu In-Reply-To: <13a83ca10605101350y5469d3e8q92c0179460ef3451@mail.gmail.com> References: <13a83ca10605101350y5469d3e8q92c0179460ef3451@mail.gmail.com> Message-ID: > Kirby (???? ), your incredible, you're everywhere ;) > http://en.wikipedia.org/wiki/Kirby_(Nintendo) > > francois I'm also in a Disney film. Three eyes. Kirby From andre.roberge at gmail.com Thu May 11 03:57:27 2006 From: andre.roberge at gmail.com (Andre Roberge) Date: Wed, 10 May 2006 22:57:27 -0300 Subject: [Edu-sig] Crunchy Frog 0.3 released Message-ID: <7528bcdd0605101857y7f6e8bb9k83633c158b845402@mail.gmail.com> Version 0.3 of "Crunchy Frog" has been released. It can be found at https://sourceforge.net/project/showfiles.php?group_id=125834 Crunchy Frog transforms a "traditional" Python tutorial into an interactive session within your favourite web browser. Four modes of interaction are currently possible: 1. One-liner, similar to the typical instruction at the Python interpreter. *NEW* 2. Embedded Python shell, within an html page. This is a bit similar to Ian Bicking's HTConsole. 3. Multi-line Python code, as entered in a traditional editor, and executed by Python. 4. Solutions to doctests, as described by Jeff Elkner in a post on edu-sig. Even though it is an early release, Crunchy Frog could probably already be useful in a classroom situation. To use it, you will also need to have installed Elementtree and CherryPy. Suggestion: read the 6 page long "tutorial" included, using your favourite browser. Then, start Crunchy Frog, and go through the tutorial again. The whole thing should be doable in approximately 15 minutes (20 for Kirby, according to a previous message ;-) ... if you don't spend too much time playing with the new interpreter. :-) Andr? From radenski at chapman.edu Thu May 11 07:18:41 2006 From: radenski at chapman.edu (Radenski, Atanas) Date: Wed, 10 May 2006 22:18:41 -0700 Subject: [Edu-sig] Difficulties in the Python-to-Java transition? Message-ID: I am among those who advocate and actually use Python in introductory CS1-type of courses, and who use Java in more advanced CS-2 type of courses (at Chapman University, California). I have witnessed concerns of some instructors in other institutions that their students find the transition from Python to Java *difficult*. The smoothness of the Python-to-Java transition seems an important issue to me. The purpose of this message is to report my experience with the Python-to-Java transition, and to possibly learn more of other instructors' experiences. In the spring semester of 2006, an end-of-semester survey polled my students of their perception of Python, Java, and the transition from Python to Java. The surveyed students are from a CS2-Java class who has been preceded by a CS1-Python class. The survey shows that the transition from Python to Java has been smooth, and that students do like both Python and Java. Students credit highly Python as a language that has prepared them to manage and succeed with Java. Here are the principal results of my Spring 2006 end-of-semester survey. Allowed responses vary from 1 (strongly DISAGREE) to 5 (strongly AGREE). Average responses on a 1 to 5 scale are given below in brackets. (Q1) Your transition from Python to Java has been smooth. [ 4.0 ] (Q2) Your preliminary study of Python has helped you learn Java. [ 4.2 ] (Q3) You like Python [ 4.0 ] (Q4) You like Java [ 4.0 ] Survey results are published at http://studypack.com (main menu, left lower part of the home page). After two years of experience with this type of courses, my impression is that initially a few CS2-Java students feel they like Python better than Java. This bias disappears in the second half of the CS2-Java course. Students learn to appreciate and enjoy both languages. I conclusion, I have not faced difficulties in the Python-to-Java transition. Of course, different instructors may have different experiences. I would like to continue learning of other instructors' experiences with the transition from Python to compiled languages, such as Java. Respectfully, Atanas Radenski mailto:radenski at chapman.edu http://www.chapman.edu/~radenski/ There are wavelengths that people cannot see, there are sounds that people cannot hear, and may be computers have thought that people cannot think -- Richard Hamming From cce at clarkevans.com Thu May 11 08:53:59 2006 From: cce at clarkevans.com (Clark C. Evans) Date: Thu, 11 May 2006 02:53:59 -0400 Subject: [Edu-sig] Google SoC mentors? In-Reply-To: <1F54B80D-AA3F-4A22-9505-F809F7A68CDA@stratolab.com> References: <4456D5D5.109@colorstudy.com> <1F54B80D-AA3F-4A22-9505-F809F7A68CDA@stratolab.com> Message-ID: <20060511065359.GD74325@prometheusresearch.com> The student's name is Johannes Wollard, and an external version of the proposal is at: http://users.ox.ac.uk/~orie1763/coder-python.pdf This is the only decent educational proposal that hit the SoC program, and it if you all like it... it is time to speak up ;) Best, Clark On Tue, May 02, 2006 at 03:19:15PM -0400, Winston Wolff wrote: | I'm interested. Would you send me that IDE description? | | -ww | | On May 1, 2006, at 11:45 PM, Ian Bicking wrote: | | > Are there other people here signed up to mentor for the Google | > Summer of | > Code? Last year PSF rejected a couple good education proposals for | > lack | > of an appropriate mentor. Already one of the proposals is for an IDE | > similar to what Andre has described (GUI not web). (If anyone is | > curious about it, I can email you the proposal off list.) | > | > -- | > Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org | > _______________________________________________ | > Edu-sig mailing list | > Edu-sig at python.org | > http://mail.python.org/mailman/listinfo/edu-sig | | | | | ______________________________________________________ | winston wolff - (646) 827-2242 - http://www.stratolab.com | learning by creating - video game courses for kids in new york | | | _______________________________________________ | Edu-sig mailing list | Edu-sig at python.org | http://mail.python.org/mailman/listinfo/edu-sig | From andre.roberge at gmail.com Thu May 11 12:24:23 2006 From: andre.roberge at gmail.com (Andre Roberge) Date: Thu, 11 May 2006 07:24:23 -0300 Subject: [Edu-sig] Google SoC mentors? In-Reply-To: <20060511065359.GD74325@prometheusresearch.com> References: <4456D5D5.109@colorstudy.com> <1F54B80D-AA3F-4A22-9505-F809F7A68CDA@stratolab.com> <20060511065359.GD74325@prometheusresearch.com> Message-ID: <7528bcdd0605110324p7c94341bnde9753bdf28935ec@mail.gmail.com> On 5/11/06, Clark C. Evans wrote: > The student's name is Johannes Wollard, > and an external version of the proposal is at: > http://users.ox.ac.uk/~orie1763/coder-python.pdf > > This is the only decent educational proposal that hit the SoC > program, and it if you all like it... it is time to speak up ;) I have been corresponding with Johannes, so I don't feel I should "vote" on the proposal. However, I feel I should try to share a few observations. For those that read Johannes's initial version, you may remember that he was proposing a wxPython based project, and that there was no statement like "the vast majority of educational programming software has been based on Logo". In our email exchanges, I mentioned: 1. the existence of rur-ple and Guido van Robot ("hence, the Logo like statement"), both with included lessons (significantly more for rur-ple). = Johannes, rightly so, does not want to reinvent the wheel. 2. The move for Guido van Robot from wxPython to Gtk (on platform other than Windows) and the fact that Ubuntu and, more importantly, Edubuntu would not include any wxPython based app as part of any "endorsed" distribution. = Edubuntu should be a natural target for such project. 3. The existence of "Crunchy Frog", a "desktop web app" designed for viewing interactive tutorials through a webbrowser. I mentioned various aspects (svg graphics for graphics, pygame sounds if run locally, possibility of remote server if the sandboxing issue is addressed, etc.). = It appears that Johannes was influenced by this in the latest version of his proposal. I mention those specific details not for the details themselves, but to illustrate that Johannes appears to be very serious about trying to work on the right thing, and put the effort into rewriting his proposal (at least 3 times, I believe). I told him right off the bat that I was not involved in the decision making process for this project, nor could I be an "official mentor" - so he was not doing this to try to impress me particularly. In fact, I haven't heard from him after a flurry of initial email exchanges. [after this email exchange with Johannes, I sent an email to the python soc list, indicating my interest in being a co-mentor for education related projects.] In short: Johannes listens to others, and seems to be ready to work hard. Do I believe that such project is needed? Since I created rur-ple and Crunchy Frog, you can guess what the answer is ;-) I hope it helps whomever has to make a decision! Andr? > > Best, > > Clark > > On Tue, May 02, 2006 at 03:19:15PM -0400, Winston Wolff wrote: > | I'm interested. Would you send me that IDE description? > | > | -ww > | > | On May 1, 2006, at 11:45 PM, Ian Bicking wrote: > | > | > Are there other people here signed up to mentor for the Google > | > Summer of > | > Code? Last year PSF rejected a couple good education proposals for > | > lack > | > of an appropriate mentor. Already one of the proposals is for an IDE > | > similar to what Andre has described (GUI not web). (If anyone is > | > curious about it, I can email you the proposal off list.) > | > > | > -- > | > Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org > | > _______________________________________________ > | > Edu-sig mailing list > | > Edu-sig at python.org > | > http://mail.python.org/mailman/listinfo/edu-sig > | > | > | > | > | ______________________________________________________ > | winston wolff - (646) 827-2242 - http://www.stratolab.com > | learning by creating - video game courses for kids in new york > | > | > | _______________________________________________ > | Edu-sig mailing list > | Edu-sig at python.org > | http://mail.python.org/mailman/listinfo/edu-sig > | > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > From winstonw at stratolab.com Thu May 11 15:24:33 2006 From: winstonw at stratolab.com (Winston Wolff) Date: Thu, 11 May 2006 09:24:33 -0400 Subject: [Edu-sig] Setting a variable's value Message-ID: <7687BC4A-2E41-4A53-8807-33ECD66E48D9@stratolab.com> I'm considering a proposal for Python 3000 and want to get some other opinions. I propose adding an alternative syntax for assigning a value to a variable so that the Python statement: a = 1 could also be written: a := 1 The reason is to help students who are familiar with the Algebraic meaning of "a = 1" (a is always equal to one) and get confused when the Python meaning of "a = 1" (put the value of one into the variable a). I teach middle and high-school students who are learning Algebra at the same time as Python, and it is very confusing to them when the same symbols mean two subtly different things. I would propose that the second syntax (a := 1), be available so that I could introduce that in the first semester course. Later, once they understood the meaning of "a := 1", they could switch the shorter syntax "a = 1". Any opinions? -Winston ______________________________________________________ winston wolff - (646) 827-2242 - http://www.stratolab.com learning by creating - video game courses for kids in new york From aharrin at luc.edu Thu May 11 15:40:27 2006 From: aharrin at luc.edu (Andrew Harrington) Date: Thu, 11 May 2006 08:40:27 -0500 Subject: [Edu-sig] Setting a variable's value In-Reply-To: <7687BC4A-2E41-4A53-8807-33ECD66E48D9@stratolab.com> References: <7687BC4A-2E41-4A53-8807-33ECD66E48D9@stratolab.com> Message-ID: <44633ECB.8050004@luc.edu> Winston, I like the pedogogy for a math teacher. I think I could even see it in a regular Python course for maybe the first day. I don't think it could be misinterpreted by interpreter or human. I would suggest including in the proposal an optional directive that would force the use of := like we have now for // and /. The question comes, then what about equality testing? Going to single = from double = would never fly, but I guess giving a meaning to unusual symbols like := and == is much less confusing than a nonstandard (mathematically) use of =. Andy Winston Wolff wrote: >I'm considering a proposal for Python 3000 and want to get some other >opinions. I propose adding an alternative syntax for assigning a >value to a variable so that the Python statement: > a = 1 >could also be written: > a := 1 >The reason is to help students who are familiar with the Algebraic >meaning of "a = 1" (a is always equal to one) and get confused when >the Python meaning of "a = 1" (put the value of one into the variable >a). > >I teach middle and high-school students who are learning Algebra at >the same time as Python, and it is very confusing to them when the >same symbols mean two subtly different things. I would propose that >the second syntax (a := 1), be available so that I could introduce >that in the first semester course. Later, once they understood the >meaning of "a := 1", they could switch the shorter syntax "a = 1". > >Any opinions? > >-Winston > > > >______________________________________________________ >winston wolff - (646) 827-2242 - http://www.stratolab.com >learning by creating - video game courses for kids in new york > > >_______________________________________________ >Edu-sig mailing list >Edu-sig at python.org >http://mail.python.org/mailman/listinfo/edu-sig > > -- Andrew N. Harrington Computer Science Department Undergraduate Program Director Loyola University Chicago http://www.cs.luc.edu/~anh 512B Lewis Towers (office) Office Phone: 312-915-7982 Snail mail to Lewis Towers 416 Dept. Fax: 312-915-7998 820 North Michigan Avenue aharrin at luc.edu Chicago, Illinois 60611 From kirby.urner at gmail.com Thu May 11 15:43:26 2006 From: kirby.urner at gmail.com (kirby urner) Date: Thu, 11 May 2006 06:43:26 -0700 Subject: [Edu-sig] Setting a variable's value In-Reply-To: <7687BC4A-2E41-4A53-8807-33ECD66E48D9@stratolab.com> References: <7687BC4A-2E41-4A53-8807-33ECD66E48D9@stratolab.com> Message-ID: > Any opinions? > > -Winston I'm generally against making any changes to Python syntax (even when it comes to adding redundant options) where the justification involves "making it easier for kids to..." I don't think that's an appropriate justification for cluttering up the language. On the other hand, it's an open source language and you're perfectly free to customize a classroom edition that does as you describe. It'd be a mutant edition though, not mainstream Python. ...Would be my preference. Kirby From vceder at canterburyschool.org Thu May 11 15:50:45 2006 From: vceder at canterburyschool.org (Vern Ceder) Date: Thu, 11 May 2006 09:50:45 -0400 Subject: [Edu-sig] Setting a variable's value In-Reply-To: <7687BC4A-2E41-4A53-8807-33ECD66E48D9@stratolab.com> References: <7687BC4A-2E41-4A53-8807-33ECD66E48D9@stratolab.com> Message-ID: <44634135.80102@canterburyschool.org> I also teach Python in that age range and I've seen the same confusion, so I know what you mean. OTOH, I wonder if it's worth a change in the language to delay facing the fact that code is not algebra. It's always seemed to me that once they get the idea that code doesn't necessarily follow the rules of algebra (which it doesn't in many ways) the symbol isn't such a big deal. And maybe it's all of that Pascal (and Delphi) code still giving me nightmares, but reviving ":=" gives me the willies... :) JMHO, Vern Winston Wolff wrote: > I'm considering a proposal for Python 3000 and want to get some other > opinions. I propose adding an alternative syntax for assigning a > value to a variable so that the Python statement: > a = 1 > could also be written: > a := 1 > The reason is to help students who are familiar with the Algebraic > meaning of "a = 1" (a is always equal to one) and get confused when > the Python meaning of "a = 1" (put the value of one into the variable > a). > > I teach middle and high-school students who are learning Algebra at > the same time as Python, and it is very confusing to them when the > same symbols mean two subtly different things. I would propose that > the second syntax (a := 1), be available so that I could introduce > that in the first semester course. Later, once they understood the > meaning of "a := 1", they could switch the shorter syntax "a = 1". > > Any opinions? > > -Winston > > > > ______________________________________________________ > winston wolff - (646) 827-2242 - http://www.stratolab.com > learning by creating - video game courses for kids in new york > > > _______________________________________________ > 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 From andre.roberge at gmail.com Thu May 11 15:57:17 2006 From: andre.roberge at gmail.com (Andre Roberge) Date: Thu, 11 May 2006 10:57:17 -0300 Subject: [Edu-sig] Setting a variable's value In-Reply-To: <7687BC4A-2E41-4A53-8807-33ECD66E48D9@stratolab.com> References: <7687BC4A-2E41-4A53-8807-33ECD66E48D9@stratolab.com> Message-ID: <7528bcdd0605110657w4564f8fft93dd49b41b57c1a6@mail.gmail.com> On 5/11/06, Winston Wolff wrote: > I'm considering a proposal for Python 3000 and want to get some other > opinions. I propose adding an alternative syntax for assigning a > value to a variable so that the Python statement: > a = 1 > could also be written: > a := 1 > The reason is to help students who are familiar with the Algebraic > meaning of "a = 1" (a is always equal to one) and get confused when > the Python meaning of "a = 1" (put the value of one into the variable > a). > > I teach middle and high-school students who are learning Algebra at > the same time as Python, and it is very confusing to them when the > same symbols mean two subtly different things. I would propose that > the second syntax (a := 1), be available so that I could introduce > that in the first semester course. Later, once they understood the > meaning of "a := 1", they could switch the shorter syntax "a = 1". > > Any opinions? > Since you ask!... I do not like it. In Python you can do things like a += 1 a -= 1 a *= 1 a /= 1 # :-) Many students will be familiar with ":" meaning division or ratio. In the context above, what would you think a := 1 should mean? Sooner or later, students have to learn that equality is (tested with) "==" in Python, not with "=". "There should be one-- and preferably only one --obvious way to do it." I don't believe in adding special notation specifically designed for beginner's sake - even though I am dedicated in making Python as easy to learn as possible. Andr? > -Winston > > > > ______________________________________________________ > winston wolff - (646) 827-2242 - http://www.stratolab.com > learning by creating - video game courses for kids in new york > > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > From andre.roberge at gmail.com Thu May 11 15:57:35 2006 From: andre.roberge at gmail.com (Andre Roberge) Date: Thu, 11 May 2006 10:57:35 -0300 Subject: [Edu-sig] Setting a variable's value In-Reply-To: <7687BC4A-2E41-4A53-8807-33ECD66E48D9@stratolab.com> References: <7687BC4A-2E41-4A53-8807-33ECD66E48D9@stratolab.com> Message-ID: <7528bcdd0605110657r5e84cae7v3bb80a4870d23f8b@mail.gmail.com> On 5/11/06, Winston Wolff wrote: > I'm considering a proposal for Python 3000 and want to get some other > opinions. I propose adding an alternative syntax for assigning a > value to a variable so that the Python statement: > a = 1 > could also be written: > a := 1 > The reason is to help students who are familiar with the Algebraic > meaning of "a = 1" (a is always equal to one) and get confused when > the Python meaning of "a = 1" (put the value of one into the variable > a). > > I teach middle and high-school students who are learning Algebra at > the same time as Python, and it is very confusing to them when the > same symbols mean two subtly different things. I would propose that > the second syntax (a := 1), be available so that I could introduce > that in the first semester course. Later, once they understood the > meaning of "a := 1", they could switch the shorter syntax "a = 1". > > Any opinions? > Since you ask!... I do not like it. In Python you can do things like a += 1 a -= 1 a *= 1 a /= 1 # :-) Students will be familiar with ":" meaning div > -Winston > > > > ______________________________________________________ > winston wolff - (646) 827-2242 - http://www.stratolab.com > learning by creating - video game courses for kids in new york > > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > From kirby.urner at gmail.com Thu May 11 16:18:41 2006 From: kirby.urner at gmail.com (kirby urner) Date: Thu, 11 May 2006 07:18:41 -0700 Subject: [Edu-sig] Setting a variable's value In-Reply-To: References: <7687BC4A-2E41-4A53-8807-33ECD66E48D9@stratolab.com> <7528bcdd0605110657w4564f8fft93dd49b41b57c1a6@mail.gmail.com> Message-ID: > I don't believe in adding special notation specifically designed for > beginner's sake - even though I am dedicated in making Python as easy > to learn as possible. > > Andr? > Right. Also, math notations which went to the trouble to be self-executing on a machine (like APL), in some sense deserve our respect for their precision and consistency. Maybe it's plain old, non-executing (dead) algebra that should change. Phase in Python notation much earlier and discuss the old pre-Python use of the assignment operator as "from a different namespace" (perhaps deprecated). Just because a bunch of oldies used typography the way they did, doesn't mean we have to warp everything we do in future to be backward compatible. I look at self-executing math notations as defining a cutting edge, not as poor imitators of some obsolote text book way of doing things. In fact, why do we teach "algebra" at all in the old fashioned sense? In my view, tackling this set of topics without a computer language is indefensible except in cases where some invading/conquering power has an agenda of keeping the kids dumb (in which case, the *real* schools have to go underground, as is happening in the USA). Kirby > > -Winston > > > > > > > > ______________________________________________________ > > winston wolff - (646) 827-2242 - http://www.stratolab.com > > learning by creating - video game courses for kids in new york > > > > > > _______________________________________________ > > Edu-sig mailing list > > Edu-sig at python.org > > http://mail.python.org/mailman/listinfo/edu-sig > > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > From nageshwar at students.iiit.net Thu May 11 16:11:55 2006 From: nageshwar at students.iiit.net (Nageshwar M) Date: Thu, 11 May 2006 19:41:55 +0530 (IST) Subject: [Edu-sig] A small module Message-ID: Hello, I have written a small module called `curstat` for python. By using this module we can get process info, memory usage stats, systeminfo ,users currently logged in and their information in list format (works only on linux platform). You can get the package from here http://students.iiit.net/~nageshwar/rpms/ Thanks, Nageshwar M From driscollkevin at gmail.com Thu May 11 19:49:17 2006 From: driscollkevin at gmail.com (Kevin Driscoll) Date: Thu, 11 May 2006 13:49:17 -0400 Subject: [Edu-sig] Setting a variable's value In-Reply-To: References: <7687BC4A-2E41-4A53-8807-33ECD66E48D9@stratolab.com> <7528bcdd0605110657w4564f8fft93dd49b41b57c1a6@mail.gmail.com> Message-ID: <87a8578e0605111049i2c4f4e17ya0188d77aa0fd0ce@mail.gmail.com> How timely! I just finished teaching this exact nuance to my 9th graders an hour ago! We began by assigning strings, floats, and integers to a set of variables to demonstrate how variables different from Algebra to Python. When it came to = vs. ==, it was easy to reference the earlier work and say, "Here's another place where Python and your Algebra notation differ." I heard no complaints and only saw one or two errors in students' code. I have to admit that := seems more confusing as it looks a lot like comparison operators >=, <=, and !=. (Plus, it chills the Pascal in my bone marrow!) Kevin On 5/11/06, kirby urner wrote: > > I don't believe in adding special notation specifically designed for > > beginner's sake - even though I am dedicated in making Python as easy > > to learn as possible. > > > > Andr? > > > > Right. > > Also, math notations which went to the trouble to be self-executing on > a machine (like APL), in some sense deserve our respect for their > precision and consistency. > > Maybe it's plain old, non-executing (dead) algebra that should change. > > Phase in Python notation much earlier and discuss the old pre-Python > use of the assignment operator as "from a different namespace" > (perhaps deprecated). > > Just because a bunch of oldies used typography the way they did, > doesn't mean we have to warp everything we do in future to be backward > compatible. > > I look at self-executing math notations as defining a cutting edge, > not as poor imitators of some obsolote text book way of doing things. > > In fact, why do we teach "algebra" at all in the old fashioned sense? > > In my view, tackling this set of topics without a computer language is > indefensible except in cases where some invading/conquering power has > an agenda of keeping the kids dumb (in which case, the *real* schools > have to go underground, as is happening in the USA). > > Kirby > > > > -Winston > > > > > > > > > > > > ______________________________________________________ > > > winston wolff - (646) 827-2242 - http://www.stratolab.com > > > learning by creating - video game courses for kids in new york > > > > > > > > > _______________________________________________ > > > Edu-sig mailing list > > > Edu-sig at python.org > > > http://mail.python.org/mailman/listinfo/edu-sig > > > > > _______________________________________________ > > Edu-sig mailing list > > Edu-sig at python.org > > http://mail.python.org/mailman/listinfo/edu-sig > > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > From delza at livingcode.org Thu May 11 20:06:26 2006 From: delza at livingcode.org (Dethe Elza) Date: Thu, 11 May 2006 11:06:26 -0700 Subject: [Edu-sig] Setting a variable's value In-Reply-To: References: <7687BC4A-2E41-4A53-8807-33ECD66E48D9@stratolab.com> <7528bcdd0605110657w4564f8fft93dd49b41b57c1a6@mail.gmail.com> Message-ID: <24d517dd0605111106i46d1828fw5edb4a9b68120c54@mail.gmail.com> On 5/11/06, kirby urner wrote: > Maybe it's plain old, non-executing (dead) algebra that should change. > > Phase in Python notation much earlier and discuss the old pre-Python > use of the assignment operator as "from a different namespace" > (perhaps deprecated). > > Just because a bunch of oldies used typography the way they did, > doesn't mean we have to warp everything we do in future to be backward > compatible. > > I look at self-executing math notations as defining a cutting edge, > not as poor imitators of some obsolote text book way of doing things. > > In fact, why do we teach "algebra" at all in the old fashioned sense? > > In my view, tackling this set of topics without a computer language is > indefensible except in cases where some invading/conquering power has > an agenda of keeping the kids dumb (in which case, the *real* schools > have to go underground, as is happening in the USA). > > Kirby This is beautifully put, so much so that I had to forward it to my wife (who's not a pythonista, but in Education). So much to think about here in such a short email. I know this is basically the gist of what you've been talking about for some time, Kirby, but this is such a succinct way of putting it that I'm in awe, and inspired. My kids haven't gotten to algebra in school yet, but were introduced to it in the "Reader Rabbit" edutainment software from a very young age. Now I'm thinking how to move that style of teaching into a more interactive, self-directed tool incorporating python. Hmmm. --Dethe From john.zelle at wartburg.edu Thu May 11 21:48:18 2006 From: john.zelle at wartburg.edu (John Zelle) Date: Thu, 11 May 2006 14:48:18 -0500 Subject: [Edu-sig] Setting a variable's value In-Reply-To: References: <7687BC4A-2E41-4A53-8807-33ECD66E48D9@stratolab.com> Message-ID: <200605111448.19068.john.zelle@wartburg.edu> On Thursday 11 May 2006 09:18, kirby urner wrote: > > I don't believe in adding special notation specifically designed for > > beginner's sake - even though I am dedicated in making Python as easy > > to learn as possible. > > > > Andr? > > Right Agreed. But I personally feel that = for assignment _is_ a bad idea, precisely because it does conflict with an older, equally valid, completely entrenched, and closely related uses of this symbol. One of the most common mistakes I still see (and make) is using = in conditions where == is needed. At least that's a syntax error in Python. The use of = is a poor desgin decision made by earlier languages and then borrowed by Python. I can live with it, but it's still a mistake. > . > > Also, math notations which went to the trouble to be self-executing on > a machine (like APL), in some sense deserve our respect for their > precision and consistency. > > Maybe it's plain old, non-executing (dead) algebra that should change. Give me a break here. If Python had used + to mean subtraction, would you say that's not a design flaw even though + means addition everywhere else in the world? That's just silly. = means equality, always has and always will in mathematics. Why should that change? > Phase in Python notation much earlier and discuss the old pre-Python > use of the assignment operator as "from a different namespace" > (perhaps deprecated). > > Just because a bunch of oldies used typography the way they did, > doesn't mean we have to warp everything we do in future to be backward > compatible. > > I look at self-executing math notations as defining a cutting edge, > not as poor imitators of some obsolote text book way of doing things. But self-executing is not the same as self-manipulating. Algebra is much more a symbolic activity than it is a numeric activity. We should use notations for algebra that best lend themselves to algebraic manipulation, not those that are necessarily best for computing results. > In fact, why do we teach "algebra" at all in the old fashioned sense? Because you need to be able to do algebra to figure out how to write (good) code. It doesn't matter much what system is interpreting that code. > In my view, tackling this set of topics without a computer language is > indefensible except in cases where some invading/conquering power has > an agenda of keeping the kids dumb (in which case, the *real* schools > have to go underground, as is happening in the USA). I fear the day that my students have no exposure to algebra outside of the sphere of computer programming. I agree with Kirby that teaching with a programming approach can be a great complement to traditional approaches, but I don't think that work on the computer produces the exact same skill set, especially pattern recognition and symbolic thinking, that plain old algebra and geometry do. Good geometry students make good programmers. --John -- John M. Zelle, Ph.D. Wartburg College Professor of Computer Science Waverly, IA john.zelle at wartburg.edu (319) 352-8360 From winstonw at stratolab.com Thu May 11 23:09:01 2006 From: winstonw at stratolab.com (Winston Wolff) Date: Thu, 11 May 2006 17:09:01 -0400 Subject: [Edu-sig] Setting a variable's value In-Reply-To: <44634135.80102@canterburyschool.org> References: <7687BC4A-2E41-4A53-8807-33ECD66E48D9@stratolab.com> <44634135.80102@canterburyschool.org> Message-ID: <38287EA0-C623-4949-A89E-B6A44F46FE84@stratolab.com> On May 11, 2006, at 9:50 AM, Vern Ceder wrote: > I also teach Python in that age range and I've seen the same > confusion, so I know what you mean. OTOH, I wonder if it's worth a > change in the language to delay facing the fact that code is not > algebra. > > It's always seemed to me that once they get the idea that code > doesn't necessarily follow the rules of algebra (which it doesn't > in many ways) the symbol isn't such a big deal. You have a good argument. I suppose since they'll need to differentiate algebra and Python soon enough, and it's just another little thing they'll have to remember. -Winston ______________________________________________________ winston wolff - (646) 827-2242 - http://www.stratolab.com learning by creating - video game courses for kids in new york From kirby.urner at gmail.com Thu May 11 23:19:09 2006 From: kirby.urner at gmail.com (kirby urner) Date: Thu, 11 May 2006 14:19:09 -0700 Subject: [Edu-sig] Setting a variable's value In-Reply-To: <200605111448.19068.john.zelle@wartburg.edu> References: <7687BC4A-2E41-4A53-8807-33ECD66E48D9@stratolab.com> <200605111448.19068.john.zelle@wartburg.edu> Message-ID: On 5/11/06, John Zelle wrote: > On Thursday 11 May 2006 09:18, kirby urner wrote: > > > I don't believe in adding special notation specifically designed for > > > beginner's sake - even though I am dedicated in making Python as easy > > > to learn as possible. > > > > > > Andr? > > > > Right > > Agreed. But I personally feel that = for assignment _is_ a bad idea, precisely > because it does conflict with an older, equally valid, completely entrenched, > and closely related uses of this symbol. One of the most common mistakes I > still see (and make) is using = in conditions where == is needed. At least > that's a syntax error in Python. The use of = is a poor desgin decision made > by earlier languages and then borrowed by Python. I can live with it, but > it's still a mistake. I think = was the most obvious single-character candidate, and in the interests of economy was chosen to keep Python spare, just like we don't need curly braces or semi-colon line endings, and enjoy complaining about some extraneous syntactic sugar colons scattered here and there. Also, let's admit it, mathematicians enjoy a lot of ambiguity in their notations, given the high end hardware they get to take for granted, and have allowed their equal sign to double as an assignment operator when convenient. They say "let x = expression" which 'let' actually made it over into BASIC (I think BASIC is what happens when you let academic committees design your language: a hodge-podge (which *is* a mistake)). > > Also, math notations which went to the trouble to be self-executing on > > a machine (like APL), in some sense deserve our respect for their > > precision and consistency. > > Mathematica too. You'll find lots of literature about how mathematicians get to be sloppy, given the very high end parsers they could take for granted. *We* know from context whether m(q - 1) is q-1 being passed to function m, or a product of two multiplicands, m and (q-1). But Mathematica had to disambiguate within its most dogmatic formalisms -- with an option to output in "sloppy" for the benefit of the computer ignorant.. > > Maybe it's plain old, non-executing (dead) algebra that should change. > > Give me a break here. If Python had used + to mean subtraction, would you say > that's not a design flaw even though + means addition everywhere else in the > world? That's just silly. = means equality, always has and always will in > mathematics. Why should that change? As I've said, it's polymorphic in mathematics as well. But yes, point granted, some mappings of ASCII to common math operations would have been subgenius, such as using & for division (although J, unlike most languages, does use %, since / was already taken). > > Phase in Python notation much earlier and discuss the old pre-Python > > use of the assignment operator as "from a different namespace" > > (perhaps deprecated). > > > > Just because a bunch of oldies used typography the way they did, > > doesn't mean we have to warp everything we do in future to be backward > > compatible. > > > > I look at self-executing math notations as defining a cutting edge, > > not as poor imitators of some obsolote text book way of doing things. > > But self-executing is not the same as self-manipulating. Algebra is much more > a symbolic activity than it is a numeric activity. We should use notations > for algebra that best lend themselves to algebraic manipulation, not those > that are necessarily best for computing results. And that would be Mathematica. So we already know: standard text book algebra notation failed the reality check. It wasn't good enough. A more formal, more rigorous notation was needed. Ergo my point: I don't look to mathematicians to tell me how to write math, but to computer scientists such as Kenneth Iverson. Although sure, I'll take suggestions from math PhD peanut gallery. But face it, most of them don't accept dot notation as a valid extension of mathematics (sheesh) and still think propositional calculus and modal logic are more important formalizations than OO -- mainly because they can't take a lot of credit for OO. Very peevish of them, and our kids suffer: no OO in K-12, but still lots of creaky old set theory (but minus its key application in SQL). An ugly situation. I have falling respect for the math teaching guild (well documented).[1] > > In fact, why do we teach "algebra" at all in the old fashioned sense? > Because you need to be able to do algebra to figure out how to write (good) > code. It doesn't matter much what system is interpreting that code. > > > In my view, tackling this set of topics without a computer language is > > indefensible except in cases where some invading/conquering power has > > an agenda of keeping the kids dumb (in which case, the *real* schools > > have to go underground, as is happening in the USA). > > I fear the day that my students have no exposure to algebra outside of the > sphere of computer programming. I agree with Kirby that teaching with a I fear the status quo much more. > programming approach can be a great complement to traditional approaches, but > I don't think that work on the computer produces the exact same skill set, Exactly. The "exact same skill set" is what we *don't* want to propagate. Not useful at this time. Need different skill sets, the sooner the better. Silicon Forest talking. > especially pattern recognition and symbolic thinking, that plain old algebra > and geometry do. Good geometry students make good programmers. > > --John Good computer graphics programmers usually end up being competent in geometry as well. Maybe we should try running the pipeline in reverse for a change, and let technology come first (wow, train kids in the power tools of their own culture, what a concept!)? That's what I'm doing, and I'm getting good results. Kirby [1] For example, just earlier today... http://controlroom.blogspot.com/2006/05/memo-to-math-teachers.html From francois.schnell at gmail.com Thu May 11 23:47:05 2006 From: francois.schnell at gmail.com (francois schnell) Date: Thu, 11 May 2006 23:47:05 +0200 Subject: [Edu-sig] Mirra 0.2.7, a 2D openGL python library with a focus on education Message-ID: <13a83ca10605111447v3e418e29k9735a8455367ab85@mail.gmail.com> Hello, My aggregator brought me this from the cheeseshop. Examples look nice. http://cheeseshop.python.org/pypi/Mirra/0.2.7 francois --- Mirra is a 2D openGL python library. It defines a set of classes to render primitive shapes (Text, Pixel, Line, Circle, Rect, Bitmap, BitmaPolygon) and manages rendering and user input (mouse, keyboard, joystick). Mirra focuses on interaction and implements an event listener and classes that receive mouse events. (in a way like macromedia director or flash do). It runs using pygame(SDL) but it can also be used under wxPython. Mirra is also thought to teach students (basically design and multimedia students) programming in python by playing around with graphics. It includes an easy to use OpenSoundControl module. --- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20060511/343b24e5/attachment.html From john.zelle at wartburg.edu Fri May 12 00:35:32 2006 From: john.zelle at wartburg.edu (John Zelle) Date: Thu, 11 May 2006 17:35:32 -0500 Subject: [Edu-sig] Setting a variable's value In-Reply-To: References: <7687BC4A-2E41-4A53-8807-33ECD66E48D9@stratolab.com> <200605111448.19068.john.zelle@wartburg.edu> Message-ID: <200605111735.32377.john.zelle@wartburg.edu> On Thursday 11 May 2006 16:19, you wrote: <> We're straying a bit from the original thread here, but I couldn't resist this comment. > Ergo my point: I don't look to mathematicians to tell me how to write > math, but to computer scientists such as Kenneth Iverson. Although > sure, I'll take suggestions from math PhD peanut gallery. > I believe Iverson used = to mean equals (as God intended it) and used <- (an arrow) to mean assignment. He knew enough not to mess with a perfectly good existing notation :-). --John -- John M. Zelle, Ph.D. Wartburg College Professor of Computer Science Waverly, IA john.zelle at wartburg.edu (319) 352-8360 From kirby.urner at gmail.com Fri May 12 00:48:20 2006 From: kirby.urner at gmail.com (kirby urner) Date: Thu, 11 May 2006 15:48:20 -0700 Subject: [Edu-sig] Setting a variable's value In-Reply-To: <200605111735.32377.john.zelle@wartburg.edu> References: <7687BC4A-2E41-4A53-8807-33ECD66E48D9@stratolab.com> <200605111448.19068.john.zelle@wartburg.edu> <200605111735.32377.john.zelle@wartburg.edu> Message-ID: > I believe Iverson used = to mean equals (as God intended it) and used <- (an > arrow) to mean assignment. He knew enough not to mess with a perfectly good > existing notation :-). > > > --John Yes, that's true and apropos. Once you've made the decision to stray from ASCII, a whole new world of custom operators opens up, along with the nightmare of custom keyboards (but hey, Princeton had 'em, and APL was the first computer language I really got to know). In J, the assignment operator is =: although =. is also meaningful (local assignment). = is a comparator. For more on J, see: http://www.4dsolutions.net/ocn/Jlang.html (Iverson himself helped me with this essay). Kirby From kirby.urner at gmail.com Fri May 12 01:18:44 2006 From: kirby.urner at gmail.com (kirby urner) Date: Thu, 11 May 2006 16:18:44 -0700 Subject: [Edu-sig] Setting a variable's value In-Reply-To: References: <7687BC4A-2E41-4A53-8807-33ECD66E48D9@stratolab.com> <200605111448.19068.john.zelle@wartburg.edu> <200605111735.32377.john.zelle@wartburg.edu> Message-ID: > For more on J, see: > http://www.4dsolutions.net/ocn/Jlang.html > (Iverson himself helped me with this essay). > > Kirby > Here, I'll declassify one from my inbox, from the late Kenneth to myself: From: Ken Iverson [mailto:kei at interlog.com] Sent: Friday, July 26, 2002 8:32 AM To: Kirby Urner Subject: Re: Jforum: New essay on J in K-12 ----- Original Message ----- From: "Kirby Urner" To: "Ken Iverson" Sent: Friday, July 26, 2002 3:39 AM Subject: Re: Jforum: New essay on J in K-12 > Tim Peters over on edu-sig (a Python list), has given me the most > informative pointer thus far: > http://www.cs.unb.ca/~alopez-o/math-faq/node40.html#SECTION00530000000000000 000 In the foregoing, it is remarked that "... you need to use a special technique such as L'Hopital's rule to evaluate them." But much insight can be gained by observing patterns produced by the power function, as shown below. (Tables appear distorted if your browser does not use a monofont such as Courier, but will appear more clearly if re-executed in J) 2^ 2 3 4 NB. Each result is 2 times the preceding 4 8 16 2^5 NB. 2^4 multiplied by 2 32 2^1 NB. 2^2 divided by 2 2 2^0 NB. 2^1 divided by 2 1 2^_1 NB. 2^0 divided by 2 0.5 e=:i:3 NB. A systematic list that includes 0 e _3 _2 _1 0 1 2 3 10^e NB. Shows pattern of powers 0.001 0.01 0.1 1 10 100 1000 0.1^e NB. Related pattern for one-tenth 1000 100 10 1 0.1 0.01 0.001 1r10 ^ e NB. Shows more clearly in rational form 1000 100 10 1 1r10 1r100 1r1000 10r1 ^ e NB. 10r1 is ten 1r1000 1r100 1r10 1 10 100 1000 1r100^ e NB. 1r100^0 remains 1 for obvious reasons 1000000 10000 100 1 1r100 1r10000 1r1000000 1 1r10 1r100 1r1000 ^/ e NB. Table shows approach to 0^0 1 1 1 1 1 1 1 1000 100 10 1 1r10 1r100 1r1000 1000000 10000 100 1 1r100 1r10000 1r1000000 1000000000 1000000 1000 1 1r1000 1r1000000 1r1000000000 1 1r10 1r100 1r1000 0 ^/ e NB. 0^0 works as defined in J 1 1 1 1 1 1 1 1000 100 10 1 1r10 1r100 1r1000 1000000 10000 100 1 1r100 1r10000 1r1000000 1000000000 1000000 1000 1 1r1000 1r1000000 1r1000000000 _ _ _ 1 0 0 0 e ^/ e NB. Table of powers shows pattern _0.037037 0.111111 _0.333333 1 _3 9 _27 _0.125 0.25 _0.5 1 _2 4 _8 _1 1 _1 1 _1 1 _1 _ _ _ 1 0 0 0 1 1 1 1 1 1 1 0.125 0.25 0.5 1 2 4 8 0.037037 0.111111 0.333333 1 3 9 27 e ^/ x:e NB. But rational form shows it more clearly _1r27 1r9 _1r3 1 _3 9 _27 _1r8 1r4 _1r2 1 _2 4 _8 _1 1 _1 1 _1 1 _1 _ _ _ 1 0 0 0 1 1 1 1 1 1 1 1r8 1r4 1r2 1 2 4 8 1r27 1r9 1r3 1 3 9 27 NB. Note the column and the row for the argument 0 (_ denotes infinity) > At the moment, it looks to me the balance is tipped in favor of > 0^0 = 1, but I'm seeing this more in the "useful convention" category, > and less in the "proved, case closed" category. To see why this might be more than a useful convention, consider the standard form for a polynomial with coefficients c. (If c has four elements, and if i is 3 2 1 0, this would be expressed in J as +/ c*x^i , and in conventonal notation as Sigma c subscript i x superscript i.) Now try to evaluate the polynomial for the case of x=:0, assuming that 0^0 is undefined. > Kirby > > PS: wonder if you've heard of John Conway's suggestion that -1 be > admitted as a prime number. No, but the inclusion of either 1 or _1 as primes would destroy the notion of the unique prime decomposition of numbers. For example: a=:q: 12345 a 3 5 823 */a 12345 1 1 1 1,a 1 1 1 1 3 5 823 */1 1 1 1,a 12345 */_1 _1 1 1,a 12345 From aharrin at luc.edu Fri May 12 17:05:03 2006 From: aharrin at luc.edu (Andrew Harrington) Date: Fri, 12 May 2006 10:05:03 -0500 Subject: [Edu-sig] Google SoC mentors? In-Reply-To: <7528bcdd0605110324p7c94341bnde9753bdf28935ec@mail.gmail.com> References: <4456D5D5.109@colorstudy.com> <1F54B80D-AA3F-4A22-9505-F809F7A68CDA@stratolab.com> <20060511065359.GD74325@prometheusresearch.com> <7528bcdd0605110324p7c94341bnde9753bdf28935ec@mail.gmail.com> Message-ID: <4464A41F.3050904@luc.edu> What is the deal on wxPython and Ubuntu and Edubuntu? Andy Andre Roberge wrote: >2. The move for Guido van Robot from wxPython to Gtk (on platform >other than Windows) and the fact that Ubuntu and, more importantly, >Edubuntu would not include any wxPython based app as part of any >"endorsed" distribution. > -- Andrew N. Harrington Computer Science Department Undergraduate Program Director Loyola University Chicago http://www.cs.luc.edu/~anh 512B Lewis Towers (office) Office Phone: 312-915-7982 Snail mail to Lewis Towers 416 Dept. Fax: 312-915-7998 820 North Michigan Avenue aharrin at luc.edu Chicago, Illinois 60611 From pdfernhout at kurtz-fernhout.com Sat May 13 18:04:59 2006 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Sat, 13 May 2006 12:04:59 -0400 Subject: [Edu-sig] PySqueak: Which 3D package should I use? Message-ID: <446603AB.8010303@kurtz-fernhout.com> Well, I've finished a simple 2D proof of concept with prototype inheritance and some user interaction of dragging (using wx): http://svn.sourceforge.net/viewcvs.cgi/patapata/PataPata/proof_of_concept_010.py?view=markup (Just dragging five related squares around, but shows basic prototype ideas in a Pythonic? style, i.e. initially you drag a parent and children move, then you drag a child and it no longer tracks the parent x,y as it has a private copy of x and y after dragging.) So, now I'm thinking of making a simple 3D version. But what 3D library to use? This has been discussed here before, for example: http://mail.python.org/pipermail/edu-sig/2003-April/002789.html but I wanted a current perspective three years later (if it has changed). The (enviable) problem is that there is so much to choose from now! See this list for example: "A small collection (72 packages) of pointers to Python software for working in three dimensions" http://www.vrplumber.com/py3d.py Which should I use from all of those 72 packages? Obviously, that depends on my needs. In the past, we bundled our own 3D graphics engine (a 3D turtle) into what we wrote, but it does finally seem like 3D graphics are common place. So, I want to go with the best current standard, and that seems to be OpenGL. In the short term, for PataPata (my PySqueak) proof of concept tests, I just want something 3D-ish that I know other people will have an easy time installing alongside their regular Python 2.3/2.4 distribution. First, I just want to put up some 3D objects that people can drag around. That's fairly simple. But later, I want to pop up GUI elements (menus, lists, editors) to support people doing Self-like things. That's harder. So, here are the longer term needs: * Python bindings (obviously :-) * OpenGL based (to get hardware acceleration). * Good current level of support and longevity. * Easy installation and configuration on Mac OS X, Windows, and GNU/Linux. * Existing support for at least the rudiments of GUI widgets in the 3D. * Not a moving target. :-) [Though perhaps I could compromise on that point if it was very cool.] I'm OK with it being complex as I plan on hiding that. I already know 3D graphics, e.g. have written my own 3D turtle and learned 3D on the SGI, though that was all many years ago, but still, I'm rusty. License really doesn't matter to me as long as it is "free" in a FSF sense and can be in the "free" part of a Debian distribution. Being lazy, and short on time, it would also be nice if it already easily handled issues like managing a world of 3D objects and knowing which was clicked on (and where). Here is an overview of that issue: http://pivy.tammura.at/documentation/pycon That issue of easily displaying 3D objects and then mapping from mouse clicks back to what is clicked on are key to the application in the long term, if I were to emulate any of what Croquet can do. It would be superb if it had widgets with openGL (lists, text, etc.) with Python bindings. Even for that, using GLUT, there are a few choices on the vrplumber page above. I have not used any such packages. I don't want to emphasize that too much though. I'm OK with working with simpler components. So it doesn't have to have everything. And it is possible I might just punt on that for now and have a separate 2D GUI for that sort of stuff. If displaying 2D widgets in 3D makes the selection of 3D graphics packages harder, even though Squeak has it, I'm OK right now even with a compromise that the 3D environment might have "control panel" objects that when you got close and clicked on them you got a separate 2D window in wx or TK on your system where you could do the usual GUI things (with sliders, etc.). In general, right now I'm fine with having a system that mixes 2D and 3D windows for different activities, though I'm sure how to do that best may be an issue, and I can see the merit of having everything in 3D to make it easier to share visible state across multiple users. Anyway, I'm wondering if I should just go with PyOpenGL, or maybe the OpenGL Context, at the start, as being fairly easy to install with the least dependencies? (I already have that running on my Debian GNU/Linux machine, though with some issues.) But other choices like VTK as a base or maybe even using Blender somehow certainly look intriguing. And, looking through recent discussions, maybe I should look harder at Soya, at the very least to get a sense of how they used various technologies? http://home.gna.org/oomadness/en/soya/index.html (Looks like it is very Python oriented, but Tom Hoffman suggested it was a tougher install...) Still, there is so much to choose from. For example, "SLUT" addresses issues I'd have down the road with Croquet style networking: http://slut.sourceforge.net/ From there: "Slut is a programming framework for generative, synthetic, interactive, network-enabled graphics." And from: http://slut.sourceforge.net/manual/index.html "Knowing Slut means knowing Python, pyOpenGL, pyGame, Twisted and Slut itself. Python is the language. OpenGL is used to draw shapes. PyGame handles sound and the integration with the operating system. And Twisted does networking." But that seems like a small project. Anyway, what 3D toolkits have people here had success with from a painless installation standpoint on typical current machines? And which ones do people think are here to stay with significant support and would feel good about using? Is plain pyOpenGL or even pyGame a "safe" choice? So many difficult decisions; maybe I will just go back to expanding the 2D proof of concepts for a while... :-) --Paul Fernhout From tom.hoffman at gmail.com Sat May 13 20:25:41 2006 From: tom.hoffman at gmail.com (Tom Hoffman) Date: Sat, 13 May 2006 14:25:41 -0400 Subject: [Edu-sig] PySqueak: Which 3D package should I use? In-Reply-To: <446603AB.8010303@kurtz-fernhout.com> References: <446603AB.8010303@kurtz-fernhout.com> Message-ID: <92de6c880605131125o762275bap43d14b8e98e70f5@mail.gmail.com> On 5/13/06, Paul D. Fernhout wrote: > I should look harder at Soya, at the very least to get a sense of how they > used various technologies? > http://home.gna.org/oomadness/en/soya/index.html > (Looks like it is very Python oriented, but Tom Hoffman suggested it was a > tougher install...) Actually, I'd forgotten that 'apt-get python-soya' works on Ubuntu at least (universe repository). I got into trouble when I tried to install from source to try some more bleeding edge features. So, to be fair, it isn't necessarily particularly difficult. --Tom From kirby.urner at gmail.com Sat May 13 21:54:26 2006 From: kirby.urner at gmail.com (kirby urner) Date: Sat, 13 May 2006 12:54:26 -0700 Subject: [Edu-sig] PySqueak: Which 3D package should I use? In-Reply-To: <446603AB.8010303@kurtz-fernhout.com> References: <446603AB.8010303@kurtz-fernhout.com> Message-ID: > So many difficult decisions; maybe I will just go back to expanding the 2D > proof of concepts for a while... :-) > > --Paul Fernhout If just trying to do some quick and dirty proof of concept work, I'd go with VPython. The API is simple. No textures, not really OpenGL, but hey, that could come later. On the OpenGL front, I'm finding Panda3D very promising, works on Edubuntu, Windows, haven't tried it on Mac (I don't think it works there yet). I haven't looked into Soyo in any detail yet. If you do, please report back on your experience. I think writing directly to OpenGL through PyOpenGL will be too much work for rapid prototyping, though I may underestimate your productivity and skills. Kirby From pdfernhout at kurtz-fernhout.com Sat May 13 22:12:43 2006 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Sat, 13 May 2006 16:12:43 -0400 Subject: [Edu-sig] PySqueak: Which 3D package should I use? In-Reply-To: <92de6c880605131125o762275bap43d14b8e98e70f5@mail.gmail.com> References: <446603AB.8010303@kurtz-fernhout.com> <92de6c880605131125o762275bap43d14b8e98e70f5@mail.gmail.com> Message-ID: <44663DBB.3020202@kurtz-fernhout.com> Tom- Thanks. apt-get install python-soya python-soya-doc just worked for me. Pulled in a bunch of stuff, but a few warnings though. Several FutureWarning but look OK. A few SyntaxWarning too. My default python is 2.3 so maybe that is it. "/usr/lib/python2.3/site-packages/soya/pudding/test.py:42: SyntaxWarning: import * only allowed at module level def test(debug = False):" Having some problems with tutorial windows locking up, like: http://home.gna.org/oomadness/en/soya_tuto/tutomodeling-1.html (which I paste into a Python prompt. :-) I can get a pyramid but the OpenGL window won't close, and I have to get out of Python (seems to tie up Gnome too, maybe their idle loop is using too much CPU? Pegs my system at 100%.). Seems like it will take some understanding (maybe that's what it is supposed to do?) So, not quite a painless out of the box experience -- not to say it is not worth using, just a datapoint on first few minutes difficulties and confusions. Still, I'm starting to lean to just using OpenGL under wx as a starter. I'm thinking that may have the least install problems for proof of concept stuff. [BTW, in the 2D realm under wx, I'm up to P.O.C. #12, with menus to add and remove morphs and tell them to do things.] Thanks again for the pointer. --Paul Fernhout Tom Hoffman wrote: > Actually, I'd forgotten that 'apt-get python-soya' works on Ubuntu at > least (universe repository). I got into trouble when I tried to > install from source to try some more bleeding edge features. > > So, to be fair, it isn't necessarily particularly difficult. From kirby.urner at gmail.com Sat May 13 23:17:52 2006 From: kirby.urner at gmail.com (kirby urner) Date: Sat, 13 May 2006 14:17:52 -0700 Subject: [Edu-sig] Pythonic Mathematics (session four) Message-ID: I had a successful breakthrough regarding my Saturday Academy class in Python Mathematics: use kepler.dodecahedron and plato.dodecahedron to show why dodecahedron alone is ambiguous and/or why a name collision might happen. That was part of a much longer thread on what I'm calling the four eras of computer programming: wild west (spaghetti code); civilized (structured programming); organic (OO); and managed (design patterns). As you may gather, I'm so far not blown away by the relevance of lambda calculus. One student asked how 3D Mandelbrot Sets were mathematically determined, given he understands the 2D case using the complex plane. I guessed using Quaternions but who wants to tell me for sure? My guess formed a good branching off point, in any case. I had 'em dive into VPython today, with just the API docs and a few pointers as I fumbled, beginner-like, in a projected IDLE session (later, I'd show them where to download a stash of canned VPython polyhedra -- a star student got it going in no time, started exploring my methods). Even the youngest had a space ship with two solar panels to show his mom when she came by to collect him. And my fractal guy, he had Saturn saved in planets.py, using a ring and a sphere object. We discovered how to do color, first by setting object.red object.green and object.blue (pause to re-explain RGB), then by setting object.color to color.somecolor (the visual.color module just has a very few -- I'd think they'd want more, especially given the lack of textures). I also downloaded, installed and booted up Panda3D on the Toshiba (my laptop on the projector). We started with Greeting Card then went exploring. One of the Panda demos quickly tosses out a 3D fractal tree with a few keyboard controls. All of these are Python programs, with the C++ API imported (I still haven't solved the dark matter problem, alluding to blog). So yes, we finally went graphical today, which was a big step. I also projected video.google of a fractal, me talking about domes, and Chieh doing one of his Tk-with-Python lectures. The technology is still a tad too low rez, so I can see where all that optical fiber might come in useful some day. We could watch Chieh in high rez and actually read what he's typing. I also shared a bit of Eskimo culture on You-tube. Last week, session three [*], was a lot of dense number theory with modulo operator, very left brain, nothing especially graphical. So I'm glad we got good and GUI today. I've been promising we would. Today I made good. Kirby [*] http://mathforum.org/kb/thread.jspa?threadID=1380445 From tom.hoffman at gmail.com Sun May 14 02:07:17 2006 From: tom.hoffman at gmail.com (Tom Hoffman) Date: Sat, 13 May 2006 20:07:17 -0400 Subject: [Edu-sig] PySqueak: Which 3D package should I use? In-Reply-To: <44663DBB.3020202@kurtz-fernhout.com> References: <446603AB.8010303@kurtz-fernhout.com> <92de6c880605131125o762275bap43d14b8e98e70f5@mail.gmail.com> <44663DBB.3020202@kurtz-fernhout.com> Message-ID: <92de6c880605131707n7a9f31b1h9be0143daf733d02@mail.gmail.com> On 5/13/06, Paul D. Fernhout wrote: > Tom- > > Thanks. > apt-get install python-soya python-soya-doc > just worked for me. > > Pulled in a bunch of stuff, but a few warnings though. > Several FutureWarning but look OK. > A few SyntaxWarning too. My default python is 2.3 so maybe that is it. > "/usr/lib/python2.3/site-packages/soya/pudding/test.py:42: SyntaxWarning: > import * only allowed at module level > def test(debug = False):" > > Having some problems with tutorial windows locking up, like: > http://home.gna.org/oomadness/en/soya_tuto/tutomodeling-1.html > (which I paste into a Python prompt. :-) > I can get a pyramid but the OpenGL window won't close, and I have to get > out of Python (seems to tie up Gnome too, maybe their idle loop is using > too much CPU? Pegs my system at 100%.). Seems like it will take some > understanding (maybe that's what it is supposed to do?) So, not quite a > painless out of the box experience -- not to say it is not worth using, > just a datapoint on first few minutes difficulties and confusions. > > Still, I'm starting to lean to just using OpenGL under wx as a starter. > I'm thinking that may have the least install problems for proof of concept > stuff. That's about as far as I got with it. My brief experience with Panda3d was more promising, but I also found both of these API's to be just too daunting. --Tom From kirby.urner at gmail.com Sun May 14 03:04:47 2006 From: kirby.urner at gmail.com (kirby urner) Date: Sat, 13 May 2006 18:04:47 -0700 Subject: [Edu-sig] Just ran into Kevin Altis... Message-ID: Kevin is the main force behind PythonCard, which adapts the wxPython API to make it even more sane. His product features an OpenGL window, but it's just a pass-through the the wx OpenGL window; I don't think PythonCard has a bunch of OpenGL-specific classes. But these could always be added to a custom version (PythonCard for Geometers say). I ran into Kevin at Zupan's, the local food market just now. I was buying provisions for a BBQ (about to happen). Kevin reminded me I haven't submitted any talk to OSCON this year, and now the deadline is passed. I'll probably be a background figure in that event this year, given we're both still in Portland. Kirby From pdfernhout at kurtz-fernhout.com Sun May 14 03:38:06 2006 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Sat, 13 May 2006 21:38:06 -0400 Subject: [Edu-sig] PySqueak: Which 3D package should I use? In-Reply-To: <92de6c880605131707n7a9f31b1h9be0143daf733d02@mail.gmail.com> References: <446603AB.8010303@kurtz-fernhout.com> <92de6c880605131125o762275bap43d14b8e98e70f5@mail.gmail.com> <44663DBB.3020202@kurtz-fernhout.com> <92de6c880605131707n7a9f31b1h9be0143daf733d02@mail.gmail.com> Message-ID: <446689FE.8060601@kurtz-fernhout.com> Tom Hoffman wrote: > That's about as far as I got with it. My brief experience with > Panda3d was more promising, but I also found both of these API's to be > just too daunting. Yes, I can see that now. If you really want all the features something like Soya provides then I can see there would be motivation to get through early hassles. But if you don't, it's hard to know if the investment is worth it given you don't know everything it can do until you see it in action. I'm really seeing the value of video on the web these days, in terms of being able to give quick overviews of what things do to motivate you to explore it on your own and get past the early problems. Those web videos are sort of a substitute for the old way of seeing new things in action by looking over someone's shoulder at the computer lab. :-). I'm up to POC #13 with a cleanup of menu handling definable by the prototypes (mostly a cleanup over #12, really), http://svn.sourceforge.net/viewcvs.cgi/patapata/PataPata/proof_of_concept_013.py?view=markup and I'm thinking now I may still try to push forward with 2D a little more and hold off on 3D proof of concepts until I get a few more ideas or evaluations on good 3D crossplatform choices (thanks also go to Kirby). Probably the move will be driven more than anything by my repeated inability to get that darn wx flicker to go away under GNU/Linux! :-) Still, it might be an opportune moment to switch because I am starting to have to be concerned over text display and composite widgets, which is often more platform specific. --Paul Fernhout From kirby.urner at gmail.com Sun May 14 06:02:41 2006 From: kirby.urner at gmail.com (kirby urner) Date: Sat, 13 May 2006 21:02:41 -0700 Subject: [Edu-sig] Pythonic Mathematics (session four) In-Reply-To: References: Message-ID: On 5/13/06, kirby urner wrote: > I had a successful breakthrough regarding my Saturday Academy class in > Python Mathematics: use kepler.dodecahedron and plato.dodecahedron to > show why dodecahedron alone is ambiguous and/or why a name collision > might happen. In case that's to esoteric for some non-geometers here: there are two basic dodecahedral polyhedra that every grade schooler should know about: (a) the Platonic pentagonal one, and (b) the space-filler Kepler researched quite a bit: the rhombic dodecahedron. So by making two namespaces, plato and kepler... Anyway, you get the idea. Kirby From pdfernhout at kurtz-fernhout.com Sun May 14 15:45:01 2006 From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout) Date: Sun, 14 May 2006 09:45:01 -0400 Subject: [Edu-sig] Just ran into Kevin Altis... In-Reply-To: References: Message-ID: <4467345D.1060902@kurtz-fernhout.com> Kirby- Thanks for the (indirect) reminder about this. Portland does sound like a happening place. :-) http://www.unconventionalideas.com/walkability.html http://www.unconventionalideas.com/eastbank.html To run the version in Debian to see what PythonCard-ers have been up to recently, I just now had to upgrade from wx 2.4 to wx 2.6 and that also fixed my flicker problem. :-) So, proof of concept fourteen, with text morphs and no flicker under wx GTK 2.6: http://svn.sourceforge.net/viewcvs.cgi/patapata/PataPata/proof_of_concept_014.py?view=log Anyway, I am confronted with a series of choice points and paths as I look at how to build a Self-like inspector (which needs GUI widgets including a text editor): * 3D right now? * How to put up interactive widgets (custom vs. wx, tk, pyGame, GLUT, other)? * Whether to keep the programming widgets in the same world window as the application or have them in another window (and/or world) or even another VM interacting over the network? Likely there is some deeply Pythonic (glue-ish and platform agnostic) way to approach these decisions I don't see yet. Still, I feel confronted by the biggest fork in the road -- focusign on the Squeak/Self notion of a consistent world of objects to present to novices and experts alike manipulated in a consistent way (if you drink the Koolaid :-), and an eclectic, throw whatever the paradigm and tool of the moment is at them that gets a specific task done approach (requiring a lot of glue sniffing :-). [***] A fundamental divide, and discussed here before. Clearly, I think the Pythonic approach is more in the latter glue oriented way. But, that perhaps requires certain assumptions about the order things are learned in or presented in, to manage complexity and information overload. Anyway, lots of decisions... So, a good time to revisit how other projects like PythonCard are doing things. If I could wrap a wxWidget in a Morph, I might get a lot of mileage out of that, and PythonCard undoubtedly has an approach to dragging widgets that might be useful (let alone if much of PythonCard could be adapted in a prototype way, since PythonCard is prototypish anyway, even if I initially used just, say, their menu editor). I mentioned long ago the notion of PySqueak and PythonCard perhaps merging somehow; perhaps time to look more deeply at the paradigms behind various approaches and their potential initial compatability. Anyway, still mainly just exploring possiblities at this point. --Paul Fernhout *** Sadly, glue sniffing is a serious problem among school kids apparently, see for example the 20% statistic here: http://emeritus.blogspot.com/2006/04/inhalant-abuse.html Maybe exciting Python-based constructivist virtual worlds (and a better real world emerging out of them?) might help a bit with it. kirby urner wrote: > Kevin is the main force behind PythonCard, which adapts the wxPython > API to make it even more sane. > > His product features an OpenGL window, but it's just a pass-through > the the wx OpenGL window; I don't think PythonCard has a bunch of > OpenGL-specific classes. But these could always be added to a custom > version (PythonCard for Geometers say). From kirby.urner at gmail.com Sun May 14 17:32:13 2006 From: kirby.urner at gmail.com (kirby urner) Date: Sun, 14 May 2006 08:32:13 -0700 Subject: [Edu-sig] Just ran into Kevin Altis... In-Reply-To: <4467345D.1060902@kurtz-fernhout.com> References: <4467345D.1060902@kurtz-fernhout.com> Message-ID: On 5/14/06, Paul D. Fernhout wrote: > Anyway, I am confronted with a series of choice points and paths as I look > at how to build a Self-like inspector (which needs GUI widgets including a > text editor): > * 3D right now? > * How to put up interactive widgets (custom vs. wx, tk, pyGame, GLUT, other)? > * Whether to keep the programming widgets in the same world window as the > application or have them in another window (and/or world) or even another > VM interacting over the network? > Likely there is some deeply Pythonic (glue-ish and platform agnostic) way > to approach these decisions I don't see yet. All good R&D Paul. In my book, these are some of the deep issues, and finding the right combination of libraries is not an easy job. Regardless of the ultimate fate of your particular project, you're adding to your repertoire plus carving out the basis of some kind of graphical framework others might use, and that's a positive thing. Incidentally, I just bought Civilization IV for my daughter [1], so we could give my wife's new computer a workout in the newly rented workspace [2], and she (my daughter) noticed right away that it contains Python bindings of some kind. I haven't researched this yet, but I do find it exciting that a high powered game engine would make Python a part of its commercial front end, even mentioning Python on the box. >From the on-line docs: """ The Python scripting language is fully integrated throughout the game and offers experienced modders a chance to really strut their stuff! People with some programming skills will be able to do things to alter the game in interesting and extraordinary ways. For instance, all of the game interface screens are exposed to Python, so modders will be able to change the information that's displayed, as well as how it's positioned on the screen. We also use Python to create and generate all of the random map scripts that are included in the game. So, players will now have the ability to add scripted events to the game like automatically generating units when a tile is reached, having specific situations trigger automatic war, or get this, bringing back Civil Wars caused by unrest, Civ II style! """ [ http://www.2kgames.com/civ4/blog_03.htm ] We can use Python to bring back automatic civil wars caused by unrest, woo hoo. How about automatic peace? Maybe its time to cue the Quakers, get 'em more into snake charming. Russ?[3] Kevin is a big gamer by the way, but mostly Mac OS X based. Kirby [1] http://www.2kgames.com/civ4/home.htm [2] http://controlroom.blogspot.com/2006/05/personal-workspace.html [3] Russ is Python programmer I know from OSCON and Quaker-P. But he calls himself an "angry economist" so is he part of the solution or part of the problem? http://angry-economist.russnelson.com/ From francois.schnell at gmail.com Sun May 14 18:35:34 2006 From: francois.schnell at gmail.com (francois schnell) Date: Sun, 14 May 2006 18:35:34 +0200 Subject: [Edu-sig] Just ran into Kevin Altis... In-Reply-To: References: <4467345D.1060902@kurtz-fernhout.com> Message-ID: <13a83ca10605140935n65dda062lf84a5f8a99135b56@mail.gmail.com> On 14/05/06, kirby urner wrote: > > Maybe its time to cue the > Quakers, get 'em more into snake charming. Russ?[3] Concerning FPS games there is "BattleField 2" (from Electronic Arts) which use Python. Firts "news" a year ago: *"""In an interview with Lars Gustavsson of DICE, it was mentioned that Battlefield 2's modding tools are going to be delivered with the game, and that the tools are the same ones used to develop the game. The modding language in use is Python, and will support all aspects of the language."""* http://developers.slashdot.org/article.pl?sid=05/02/11/1439230 and now ... :) *"""Unlock Special Weapons (Version 1.0.0 only)* Locate the file "unlocks.py" located in Program Files\EA GAMES\Battlefield 2\python\bf2\stats (or whereever you installed Battlefield 2, in the folders \python\bf2\stats), and open "unlocks.py" with Notepad. ... """ http://www.gamespot.com/pc/action/battlefield2/hints.html francois Kevin is a big gamer by the way, but mostly Mac OS X based. > > Kirby > > [1] http://www.2kgames.com/civ4/home.htm > > [2] http://controlroom.blogspot.com/2006/05/personal-workspace.html > > [3] Russ is Python programmer I know from OSCON and Quaker-P. But he > calls himself an "angry economist" so is he part of the solution or > part of the problem? http://angry-economist.russnelson.com/ > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20060514/64a47e31/attachment.html From andre.roberge at gmail.com Sun May 14 18:55:25 2006 From: andre.roberge at gmail.com (Andre Roberge) Date: Sun, 14 May 2006 13:55:25 -0300 Subject: [Edu-sig] Fwd: [Only Python] 5/14/2006 09:29:20 AM In-Reply-To: <28855600.1147613361435.JavaMail.root@blb34.blogger.com> References: <28855600.1147613361435.JavaMail.root@blb34.blogger.com> Message-ID: <7528bcdd0605140955o47cb768fw20f24663d2052ccb@mail.gmail.com> Hi everyone, I got the following message on my blog, aroberge.blogsot.com (more below). -------- Forwarded message ---------- From: George Wright noreply-comment at blogger.com I installed Crunchy Frog 0.3 and ran the included tutorial. Really liked the DocTest approach. *It forced me to write my own programs that would produce the desired results *. Up to now I had contented myself with simply reading and understanding other people's programs. I need more python tutorials like this. Where can I find them? ===== Given that I had included docstrings as an example, based on comment by others on this list, comments to the effect that some wanted to write such docstring-based tutorials, does anyone have any suggestions? Andre -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20060514/7086b9ec/attachment.htm From francois.schnell at gmail.com Sun May 14 19:04:31 2006 From: francois.schnell at gmail.com (francois schnell) Date: Sun, 14 May 2006 19:04:31 +0200 Subject: [Edu-sig] Google SoC mentors? In-Reply-To: <4464A41F.3050904@luc.edu> References: <4456D5D5.109@colorstudy.com> <1F54B80D-AA3F-4A22-9505-F809F7A68CDA@stratolab.com> <20060511065359.GD74325@prometheusresearch.com> <7528bcdd0605110324p7c94341bnde9753bdf28935ec@mail.gmail.com> <4464A41F.3050904@luc.edu> Message-ID: <13a83ca10605141004o40327d7al9c6aed69c8e5c142@mail.gmail.com> On 12/05/06, Andrew Harrington wrote: > > What is the deal on wxPython and Ubuntu and Edubuntu? > Andy > > Andre Roberge wrote: > > >2. The move for Guido van Robot from wxPython to Gtk (on platform > >other than Windows) and the fact that Ubuntu and, more importantly, > >Edubuntu would not include any wxPython based app as part of any > >"endorsed" distribution. > > > -- > I also would like to know If possible what are the problems/deal with WxPython. francois -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20060514/4f85b6c6/attachment.html From kirby.urner at gmail.com Sun May 14 20:05:56 2006 From: kirby.urner at gmail.com (kirby urner) Date: Sun, 14 May 2006 11:05:56 -0700 Subject: [Edu-sig] Just ran into Kevin Altis... In-Reply-To: <13a83ca10605140935n65dda062lf84a5f8a99135b56@mail.gmail.com> References: <4467345D.1060902@kurtz-fernhout.com> <13a83ca10605140935n65dda062lf84a5f8a99135b56@mail.gmail.com> Message-ID: On 5/14/06, francois schnell wrote: > On 14/05/06, kirby urner wrote: > > > Maybe its time to cue the > > Quakers, get 'em more into snake charming. Russ?[3] > > > Concerning FPS games there is "BattleField 2" (from Electronic Arts) which > use Python. > Firts "news" a year ago: Great link, thank you! And that Unreal Tournament engine, were those Python bindings native then (allusion to some earlier post)? FPS = first person shooter. SM's CivIV is TPB = third person builder (all those little first persons running around tend to shoot a lot though, especially after discovering gunpowder, woo hoo). Or you could say TPB = FPG (first person god), and god *could* be a shooter. But "god versus humans" in a killing capacity tends to be no fun. They're so good at killing themselves as it is. The challenge is getting them to do anything constructive, hence the popularity of TPBs. Kirby From kirby.urner at gmail.com Sun May 14 21:23:30 2006 From: kirby.urner at gmail.com (kirby urner) Date: Sun, 14 May 2006 12:23:30 -0700 Subject: [Edu-sig] Fwd: [Only Python] 5/14/2006 09:29:20 AM In-Reply-To: <7528bcdd0605140955o47cb768fw20f24663d2052ccb@mail.gmail.com> References: <28855600.1147613361435.JavaMail.root@blb34.blogger.com> <7528bcdd0605140955o47cb768fw20f24663d2052ccb@mail.gmail.com> Message-ID: I've fallen behind on Crunchy Frog. Having been through the first version's tutorial, I was left wondering what the back end API looks like i.e. suppose I'm a teacher wanting to whip out some Crunchy Frog oeuvre d'evers, what would that look like? Do I need to know any HTML? Kirby On 5/14/06, Andre Roberge wrote: > > Hi everyone, > > I got the following message on my blog, aroberge.blogsot.com (more below). > > -------- Forwarded message ---------- > From: George Wright noreply-comment at blogger.com > > > > I installed Crunchy Frog 0.3 and ran the included tutorial. Really liked the > DocTest approach. It forced me to write my own programs that would produce > the desired results . Up to now I had contented myself with simply reading > and understanding other people's programs. I need more python tutorials like > this. Where can I find them? > ===== > Given that I had included docstrings as an example, based on comment by > others on this list, comments to the effect that some wanted to write such > docstring-based tutorials, does anyone have any suggestions? > > Andre > > _______________________________________________ > Edu-sig mailing list > Edu-sig at python.org > http://mail.python.org/mailman/listinfo/edu-sig > > > From francois.schnell at gmail.com Sun May 14 21:29:09 2006 From: francois.schnell at gmail.com (francois schnell) Date: Sun, 14 May 2006 21:29:09 +0200 Subject: [Edu-sig] Just ran into Kevin Altis... In-Reply-To: References: <4467345D.1060902@kurtz-fernhout.com> <13a83ca10605140935n65dda062lf84a5f8a99135b56@mail.gmail.com> Message-ID: <13a83ca10605141229q132ed23dhc729eb4da89aa631@mail.gmail.com> On 14/05/06, kirby urner wrote: > > > But "god versus humans" in a killing capacity tends to be no fun. > They're so good at killing themselves as it is. The challenge is > getting them to do anything constructive, hence the popularity of > TPBs. As our ancestors were hunters maybe its why FPS are also quiet popular with all kids even before videogames with plastic guns and bows (a kind of "hunting" gene remaining somewhere ? an inherited behavior or just a media/TV influence ? ). Personally I prefer to see kids practicing their old "hunting skills" in virtual worlds than becoming real hunters killing real animals just for fun. Also if they want to "survive" longer they'll have to analyse and take advantage of the "geometry" of the map they're in : you just don't run and shout in an open space like a maniac (at least in "realistic" FPS) . All that said FPS is not my cup of tea except a part for the game "Unreal Tournament 2004" that I bought because there were Linux logo on the box :). With the Linux NVDIA drivers I could at least impress my friend about 3D games on Linux. The funny thing about UT2004 is that the most popular way of playing it is the "onslaught" mod which is collaborative and tactic in the same time : you need to work in team to control vital nods up to the main enemy core, if the team doesn't collaborate and just shoot everywhere the mission is over quickly. To collaborate you use the microphone (or the chat if don't have a microphone) and *that* was the unexpected *social part*, I've learn a lot about life in russia, japan, UK, etc while practicing an old "hunting" gene with 7 to 77 years old humans :) http://en.wikipedia.org/wiki/Unreal_Tournament_2004 Concerning TPB I think they are really interesting since you can learn about history, economics, strategy while playing. A shame that it doesn't fit well the console market with their limited pad and TV-screen. francois Kirby > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/edu-sig/attachments/20060514/bf85093f/attachment.html From andre.roberge at gmail.com Sun May 14 23:18:48 2006 From: andre.roberge at gmail.com (Andre Roberge) Date: Sun, 14 May 2006 18:18:48 -0300 Subject: [Edu-sig] Fwd: [Only Python] 5/14/2006 09:29:20 AM In-Reply-To: References: <28855600.1147613361435.JavaMail.root@blb34.blogger.com> <7528bcdd0605140955o47cb768fw20f24663d2052ccb@mail.gmail.com> Message-ID: <7528bcdd0605141418m248037dex61a708677d4eba30@mail.gmail.com> On 5/14/06, kirby urner wrote: > > I've fallen behind on Crunchy Frog. > > Having been through the first version's tutorial, I was left wondering > what the back end API looks like i.e. suppose I'm a teacher wanting to > whip out some Crunchy Frog oeuvre d'evers, what would that look like? > Do I need to know any HTML? Yes, one needs to know html, or at the very least be able to make some small changes to an existing html file. My assumption is that most tutorials are available as html files. For those that haven't read the latest, hopefully more explicit tutorial, here's (in a nutshell) what Crunchy Frog requires and allows. 1. Requirement: tutorial written in (x)html. 2. Possibilities: a) Given some sample Python code (at the interpreter) in the html file: [Note: I know that I should have written >>> rather than >>> in the code below] 
>>> print "Hello world!"
Hello world!
>>> a = 6*7
>>> print a
42
One can embed a Python interpreter prompt by changing the first line above to: 

"vlam" stands for "Very Little Added Markup."

When the html file will be served to your browser by Crunchy Frog, an
interpreter (somewhat similar to Ian Bicking's HTConsole) will appear just
below the
tag, allowing the user to try to reproduce the above example, or simply try other Python code. b) Given some sample code (not an interpreter example) in an html file: 
def times2(n):
    return n*2
One can embed an "editor" (html textarea) with an "Evaluate" button next to it by changing the first line to: 

This "editor", which will appear just below the sample code again, will
allow the user to enter some code in it (perhaps the example written above)
and try running it as a Python script by pressing the "Evaluate" button.
The output will appear below. The code in the editor can then be changed,
and run again, as often as desired.

c) Given some sample "doctest" result in an html file

"""
>>> print times2(4)
8
"""


One can embed an "editor" below with an "Evaluate" button which, when
pressed, will run the above code and test to see if the doctest string can
be reproduced.  This is done by changing the first line to


There's a bit more to it than what I wrote above, but it should give the
flavor.

Andr?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20060514/e38fdb75/attachment.htm 

From chandrakirti at gmail.com  Mon May 15 00:14:51 2006
From: chandrakirti at gmail.com (Lloyd Hugh Allen)
Date: Sun, 14 May 2006 18:14:51 -0400
Subject: [Edu-sig] survey of languages final project
Message-ID: <24d253d90605141514h2eb2c2f8p746759fa98d27266@mail.gmail.com>

I just finished teaching a semester high school course of survey of
programming languages, intended for students who already had learned
Java (a handful of whom sat for the Comp Sci AP this year). If I teach
it again, I may reverse part of my sequence:

First quarter: I taught Python using notes that had been translated
from C to C++ to Java to Python along the years. Because the students
had already seen the Java version of the lectures (their Java
instructor got the original notes from the same C teacher that I did),
we were able to plow through the equivalent of a year-long programming
course in a little less than a semester, leaving some time for special
Python constructions like lists, dictionaries, string libraries,
tkinter, etc.

Second quarter: language of their choice, with projects of their
choosing (potentially with guidance); one student chose COBOL, several
perl, a Ruby, an assembly, and a C#.

Final project (which, in retrospect, would also have made a good
intro): I gave them pysteroids, a pygame package, and they were to
*make the asteroids either really fast or really slow; *make
themselves invincible (without crashing the game -- some students
learned quickly that having their health grow, perhaps through
multiplication of the computed damage instead of subtraction, would
make their health "too big" and crash the window); reverse the
controls so that left goes right and right goes left; and do at least
one other thing to dork around with the code. They were solidly
engaged for 80 minutes, even after being graded on the assignment, and
afterwards said that it was the best programming assignment they had
received. In the future I would strongly consider starting out with
this "final project." I was surprised by what some students came up
with when I suggested that they do "at least one other thing" without
specifying that other thing, and this also encouraged them to be
original (rather than, say, copying their neighbor's code) and to give
each other positive reinforcement.

For context, this class is intended for magnet seniors (roughly 18
years old) in a combination traditional (neighborhood) and magnet
school with a population of roughly 2000 students in Maryland. A
magnet school draws students from around the district who have an
interest in a particular field; in our case, they should be interested
in math, science and/or computer science; and they are required to
have passed Algebra I in middle school. I'm including this last
paragraph purely for context, not for discussion per se. Thanks!

-Lloyd Allen

From kirby.urner at gmail.com  Mon May 15 02:55:40 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Sun, 14 May 2006 17:55:40 -0700
Subject: [Edu-sig] survey of languages final project
In-Reply-To: <24d253d90605141514h2eb2c2f8p746759fa98d27266@mail.gmail.com>
References: <24d253d90605141514h2eb2c2f8p746759fa98d27266@mail.gmail.com>
Message-ID: 

On 5/14/06, Lloyd Hugh Allen  wrote:
> I just finished teaching a semester high school course of survey of
> programming languages, intended for students who already had learned
> Java (a handful of whom sat for the Comp Sci AP this year). If I teach
> it again, I may reverse part of my sequence:

Thanks for the update Lloyd.  I haven't looked into Pysteroids yet
(legal?).  Thanks for the pointer.

Kirby

From kirby.urner at gmail.com  Mon May 15 02:59:03 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Sun, 14 May 2006 17:59:03 -0700
Subject: [Edu-sig] Fwd: [Only Python] 5/14/2006 09:29:20 AM
In-Reply-To: <7528bcdd0605141418m248037dex61a708677d4eba30@mail.gmail.com>
References: <28855600.1147613361435.JavaMail.root@blb34.blogger.com>
	<7528bcdd0605140955o47cb768fw20f24663d2052ccb@mail.gmail.com>
	
	<7528bcdd0605141418m248037dex61a708677d4eba30@mail.gmail.com>
Message-ID: 

> There's a bit more to it than what I wrote above, but it should give the
> flavor.
>
> Andr?
>

Thanks.  So I could maybe have a property associate with an
interpreter box, such that returned output would be recognized as
"correct" (e.g. 42) or not.  Depending on the output, the next page
might be different.

Kirby

From kirby.urner at gmail.com  Mon May 15 03:11:18 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Sun, 14 May 2006 18:11:18 -0700
Subject: [Edu-sig] Just ran into Kevin Altis...
In-Reply-To: <13a83ca10605141229q132ed23dhc729eb4da89aa631@mail.gmail.com>
References: 
	<4467345D.1060902@kurtz-fernhout.com>
	
	<13a83ca10605140935n65dda062lf84a5f8a99135b56@mail.gmail.com>
	
	<13a83ca10605141229q132ed23dhc729eb4da89aa631@mail.gmail.com>
Message-ID: 

On 5/14/06, francois schnell  wrote:
> Personally I prefer to see kids practicing their old "hunting skills" in
> virtual worlds than becoming real hunters killing real animals just for fun.
>

I'm for that if the hunting is purely for sport and not survival.

Let 'em rent 'Deer Hunter' for the X-box or something.  Maybe put a
real shoulder kick in the rifle somehow?  Holodeck stuff.  Oh, and let
players opt to be the deer instead of the hunter.

And that point (when switching animals), many players would ask for a
stronger predator avatars (gentle deer were never that hard to kill,
were for rank beginners even in the Stone Age).

How 'bout give us something to really scare those humans silly.  ETs?

> All that said FPS is not my cup of tea except a part for the game "Unreal
> Tournament 2004"  that I bought because there were Linux logo on the box :).
> With the Linux NVDIA drivers I could at least impress my friend about 3D
> games on Linux.

'Half Life 2' for me.  It's just so good at pushing to a fascist
extreme in the opening minutes -- reminds everyone of why we fight
(except some among us secretly yearn to play quisling for the ETs --
as revealed by on target personality tests).

> Concerning TPB I think they are really interesting since you can learn about
> history, economics, strategy while playing. A shame that it doesn't fit well
> the console market with their limited pad and TV-screen.
>
> francois

Good point.  But then, I worry about such limited APIs in general, for
humans I mean.  Sure, a car is X-Box simple to operate and driving is
fun, sometimes x-tremely so.

But if that's *all* you know, you haven't really exploited some of the
deeper powers of your nervous system.  Like hey, you're human this
time, so why not milk that for what it's worth?

Like try a real keyboard sometime, combined with reading some
challenging writing, like William Shakespeare or Calvino or someone,
or maybe learn Chinese.

Kirby

From andre.roberge at gmail.com  Mon May 15 03:15:13 2006
From: andre.roberge at gmail.com (Andre Roberge)
Date: Sun, 14 May 2006 22:15:13 -0300
Subject: [Edu-sig] Fwd: [Only Python] 5/14/2006 09:29:20 AM
In-Reply-To: 
References: <28855600.1147613361435.JavaMail.root@blb34.blogger.com>
	<7528bcdd0605140955o47cb768fw20f24663d2052ccb@mail.gmail.com>
	
	<7528bcdd0605141418m248037dex61a708677d4eba30@mail.gmail.com>
	
Message-ID: <7528bcdd0605141815q2665207ds1df26e1a248bc3de@mail.gmail.com>

On 5/14/06, kirby urner  wrote:
>
> > There's a bit more to it than what I wrote above, but it should give the
> > flavor.
> >
> > Andr?
> >
>
> Thanks.  So I could maybe have a property associate with an
> interpreter box, such that returned output would be recognized as
> "correct" (e.g. 42) or not.  Depending on the output, the next page
> might be different.


At present, only standard "doctest" are run with an "expected" output.  When
run successfully, a "custum" message appears.  It would be fairly easy to
change this so that a link to a new page appears upon successful
completion.  Or, it might be modified so that it links directly to the next
page...

Note that the limitation to doctests should not be a big limitation in
practice.  Usually, students will be ask to write a function that produces a
certain result when called.  So, in the case you mention, the doctest might
be:
"""
>>> print student_function()
42
"""
Until the student writes a function (named student_function!) that returns
42, no link to the next page would be present on the page.
----------
I see the interpreter prompt as an invitation to explore, rather than a
testing environment.

If you have some "mock tutorial" (i.e. a series of exercises) that you can
give me (perhaps off-list), I could see if Crunchy Frog could (as is)
produce the type of tutorial that you'd want.  If not, it could be the next
feature I implement ;-)

Andr?



Kirby
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20060514/b93b8167/attachment-0001.htm 

From aharrin at luc.edu  Mon May 15 04:27:29 2006
From: aharrin at luc.edu (Andrew Harrington)
Date: Sun, 14 May 2006 21:27:29 -0500
Subject: [Edu-sig] An engine to navigate between lessons
In-Reply-To: <7528bcdd0605141815q2665207ds1df26e1a248bc3de@mail.gmail.com>
References: <28855600.1147613361435.JavaMail.root@blb34.blogger.com>	<7528bcdd0605140955o47cb768fw20f24663d2052ccb@mail.gmail.com>		<7528bcdd0605141418m248037dex61a708677d4eba30@mail.gmail.com>	
	<7528bcdd0605141815q2665207ds1df26e1a248bc3de@mail.gmail.com>
Message-ID: <4467E711.8080704@luc.edu>

Navigating Between Lessons

I have been reading the discussion and trying the prototypes for Python 
content delivery with great excitement.  On seeing how well you were 
doing on the content delivery, my imagination took off and I wrote down 
a whole bunch of brainstorming ideas below on an important independent 
aspect of an interactive learning environment.  Just tonight the "Only 
Python" thread touched on the area I have been thinking about with the 
idea of choosing what comes next after evaluating code in the Crunchy Frog.

I am interested in the learning model and engine for choosing the next 
lesson to present.  I imagine a nonlinear web of potential next steps 
and a flexible engine to determine the best next step.  I would like to 
consider carrying on this with like-minded folks in parallel with people 
working on the delivery environment choices and lesson/example/test 
content.    I see the lesson choosing engine as being essentially 
independent of the type of lessons being presented, so this work should 
fit into the larger Shuttleworth vision for computer based learning in 
general.

I have written a rather long document here, with an overview, some more 
nitty-gritty aspects, and ideas for moving forward.  I refer to a web 
page at the end with more specific implementation ideas.

One model is just having a lot of tutorials, and let learners choose 
which one to do and which one to do after that.  When we (hopefully) get 
an enormous number of independent contributions from our user/learner 
community dynamically added, completely manual choosing of a next 
tutorial will be onerous.  At a minimum we would like an engine to limit 
the obvious choices of where to go next, while still letting the learner 
choose.

While some learners may be self aware enough to know when they know one 
thing well enough and are ready to look for something else, others would 
like to avoid worrying about that and concentrate on the material, and 
let an intelligent engine determine when and where they should go next 
to advance toward their goal most efficiently. 

The goals tie into a separate issue of motivation and reward addressed 
in recent threads: figuring what *is* the goal and how to make it 
exciting.  Consider a learner starting from a place that immediately 
describes a bunch of different application areas that might be 
interesting.  Let learners choose goals by saying "I want to be able to 
do something like that myself!"  -- whether it be as simple as Kirby's 
neat example of a Mad Lib generator, drawing shapes with a Turtle, or as 
complicated as a dynamic web site connected to a database, or elaborate 
gaming.  Then let the skill set needed for the selected type of 
application determine the inventory of skills that the engine guides the 
learner through. 

Alternately goals could be specified by some formal body like the 
Virginia Public Schools.  The idea of letting learners choose an 
interesting application to head for could still apply.  Applications 
would be chosen that include the required competencies, with some extra 
additions depending on the target application area chosen by the 
learner.  The complete target skill set chosen would then guide the path 
the engine provides through the lessons.  Letting the learner *choose* 
to take on the elaborated goal should help keep the learner on task and 
motivated. 

To keep the rewards from being too remote, a sequence of simpler sample 
application area targets could be chosen incorporating more and more of 
the final desired skill sets.   Again these chosen goals might add a bit 
to what the learner needs to absorb and affect the path through the 
lessons, but the extra motivation should be worth it.

Anyway, to allow lessons to fit into a larger, at least partly automated 
environment, we would need some agreed upon interface for messages 
passed back and forth between lessons and the lesson choosing engine, or 
other components.

As I started thinking about this, I realized that there could be other 
useful modules integrating multiple lessons, for instance summarizing 
and reviewing exposition.  I thought of Zelle's text, where the main 
chapters have a lot of exposition with the actual syntax rules 
interspersed.  The book also has an appendix that just has the new 
syntax from each chapter in the order of the chapters.  If the learner 
forgets some syntax, and wants to check back, it would be nice to be 
able to have a window pop up with all the syntax introduced so far, in 
the order that the learner encountered it, dynamically generated from 
the particular learners' lesson history.  Or for a more general review 
see summary statements from exposition in their lesson history.  Or 
maybe see a summary of things introduced so far by grouped by some topic 
tags, ... 

There would need to be a further consistent interface to the lessons to 
do this.  (I would assume a lesson could omit implementation of one of 
these extra features, and return None to a message with a request, and 
have the system behave gracefully.) 

I'm sure I have not thought about everything in the integration of 
lessons that could be useful and would need an agreed interface to be 
able to implement it. 

The most basic data structures and interfaces would revolve around 
finely divided skill sets:  those that are prerequisites and those that 
should be learned by the end of a lesson.  I would hope we could get all 
lessons to interact on that level.   Low level skills are easiest to 
categorize, set dependencies for, and automatically test.  It will be 
more of a challenge for higher level learning outcomes, but the 
complication is likely to be in the lessons, while the basic lesson 
choosing engine would be similar.

The idea of skill sets is of course very general.  I would plan to set 
it up so the model interfaces with the certification system Jeff is 
working on for the State of Virginia.

You could have a very basic engine choosing lessons with just this 
information. You would have to depend on the learners to determine when 
they understood things well enough to go on to the next lesson. 

The next elaboration would be to send testing results in some form from 
the end of a lesson session to the central engine, indicating if the 
learner did get the desired competencies, or which subset of them, or 
that more drill is needed, or this was way too hard for the learner.  
Possibilities for the engine would be to:
   go on to the next lesson in the author's prepared sequence
   if one learning outcome was incompletely attained, go to a drill 
lesson on that learning outcome
   jump back to an alternate lesson that goes slower with more examples 
and smaller steps
   if the current module only provides exposition/exposure, go to a 
lesson that includes  testing, ....

Anyhow, agreeing on at least optional interfaces from lessons to a 
larger system would be useful.  I am interested in joining with others 
to think about that and report back.
- - - - - - - - - - - - - -
Nitty Gritty

It will of course be important to label skills that are prerequisites 
and skills demonstrated as an outcome of an exercise.  It will be harder 
to deal with the fuzzier ideas of how many creative steps are needed 
without explicit experience for a specific challenge vs. measuring how 
many steps together a learner can confidently handle while feeling 
challenged.  Hopefully as we make the engine more sophisticated, we can 
measure more individual pedagogical parameters for learners and 
incorporate them in the engine decisions.

Ideally we would not only dynamically measure the needs of a learner as 
s/he progresses, but also measure and modify the overall response of the 
system.  We first keep track of session histories locally and, with the 
user's permission, upload them to a central site to hone the engine 
choosing the best place to go next.  For instance:  we marked module N 
as closely following module M, but almost nobody got N on the first try 
after M -- now mark it as being further off, so when the engine looks 
for the best module to follow M for a learner challenged appropriately 
by a certain sized jump, it finds module M1 instead ... or FLAG: we 
really need to write an intermediate module between M and N!  We could 
measure not only the distance between lessons but the effectiveness of a 
lesson.  We could either flag a lesson as not working or dynamically 
offer up an alternate lesson that is provided, that leads students to 
the same goals faster than another.

Learning styles are very important and diverse, as I have found with my 
children and my learners.  These should be the basis of user options 
guiding the choice of modules.  For example:  introduce examples first 
vs. rules first; supply little bites vs. a major overview before looking 
for feedback; written vs. verbal or video presentation, module requires 
cognitive (grade) level N ...  A more sophisticated later approach would 
be to explicitly test the learner's learning style and then set some of 
these parameters automatically.  There are also many other user chosen 
options.  For example:  I like modules written by X, modules approved by 
Y, modules approved by a learned professor, modules using analogies to 
Java or C or music or football....

Have an easy interface to add your own lesson and label it in the 
general taxonomy so it works with the choice engine.  It would be neat 
to say to learners:  if you struggled through this, and finally got it, 
how would you redo it to make it easier for you?  Ok, do it for everyone 
who comes after you!  Upload it and label the differences in your 
presentation from the previous one (i.e. smaller step -- comes before 
the last one, or more examples provided, or just 'written by X').  A 
learner may find s/he can relate particularly well to what X writes.

On categories:  the learned professors can specify a bunch of categories 
and tags, but the deli.ci.us model shows the power of organic growth:  
what is a useful tag in practice will stick.  If we do not allow this 
initially, at least we should design a system where this would be a 
modular generalization to add.  If we are looking for user contributions 
and large organic growth, I think flexible preference/descriptor tags 
could be very useful. 

Allow a record of learning via secure external certification and also 
locally without any special security that would enforce avoidance of 
funny business.

Along the way, the learner should be able to see a display of what 
skills s/he has mastered and which remain for the current goal (either 
based on informal feedback and testing or by official certification). 

Way out in front:  For video lessons, which fit some people's learning 
style, there are very effective commercial systems to automatically 
store in real time and later compact a movie of what appears on the 
computer screen + synchronous voice.  Modern commercial systems are not 
large resource hogs.  If we are to allow anyone to add video lessons, a 
free alternative would be good to develop!

--------------------

Moving Forward

I would like to explore a more general engine since people start in 
different places, head to different personal goals, and have different 
speeds and styles of learning and different computer capacities.  Also 
we have discussed an environment that makes user contributions easy.  We 
want to dynamically integrate these contributions.  The contributions 
may not fit into preplanned niches.  All this suggest a nonlinear web of 
potential next steps and a flexible engine based on inputs including 
those listed above to determine the best next step.

If people agree that a "choose the next module" engine like this is 
useful, I would like to develop and reach agreement on the external 
interface tied into data structures for lesson dependencies, user 
preferences, and outcomes from modules.  Hopefully I will find others to 
develop it with me, moving to a more specialized list for implementation 
details, and report progress back to the main list.

Some concepts for this engine might come under well-developed 
interactive learning theory that I have not seen.  At least in the early 
brainstorming stages I am more of an "imaginer from a clean slate" than 
"searcher for what is out there to avoid reinventing the wheel".  
References to the existing "wheels" that you have seen are appreciated.  
I think there should still be a lot of room for new ideas around open 
source and a dynamic response to a network community of learners and 
contributors and having flexible relationships that do not depend on a 
static, predetermined, limited vision.

I have thought about some more detailed design ideas for classes that 
are likely to be involved.  See 
http://www.edupython.org/tutorialEngine/brainstormingEngineObjects.html

The first concrete project I would be interested in interfacing with is 
the Crunchy Frog.

-- 
  Andrew N. Harrington
  Computer Science Department      Undergraduate Program Director
  Loyola University Chicago        http://www.cs.luc.edu/~anh
  512B Lewis Towers (office)       Office Phone: 312-915-7982
  Snail mail to Lewis Towers 416   Dept. Fax:    312-915-7998
  820 North Michigan Avenue        aharrin at luc.edu
  Chicago, Illinois 60611          


From pdfernhout at kurtz-fernhout.com  Mon May 15 05:13:51 2006
From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout)
Date: Sun, 14 May 2006 23:13:51 -0400
Subject: [Edu-sig] PySqueak: More on Croquet and 3D (was: Just ran...)
In-Reply-To: 
References: 	<4467345D.1060902@kurtz-fernhout.com>
	
Message-ID: <4467F1EF.7010609@kurtz-fernhout.com>

kirby urner wrote:
> All good R&D Paul.  In my book, these are some of the deep issues, and
> finding the right combination of libraries is not an easy job.
> Regardless of the ultimate fate of your particular project, you're
> adding to your repertoire plus carving out the basis of some kind of
> graphical framework others might use, and that's a positive thing.

Thanks for the kind words.

Also, I am forced to wrestle with the issue of what are my specific 
subgoals here (thinking of a PySqueak which is easy for beginners to use 
and experts want to use as well)?
They sort of are, roughly speaking:
* to have Self prototypes in Python as an option (check, though 
inefficient :-),
* to have a Self GUI in Python (brooding over),
* to port our 3D educational software to Python and this system (half 
done, the translating to Python part, but need to settle on widgets),
* and to make Python development with running systems as interactive and 
fun to use as that of a modern Smalltalk (just scratching at the network 
debugging approach outlined earlier, but also already have the reloader 
window I use with Jython),
* 3D simulated worlds in Python (less importance now to me, but of 
potential long term interest in terms of simulation).

I've been trying out the latest version of Croquet some more as I ponder 
this 3D and widget issue. I think I am getting past the Wow factor -- 
though it still remains pretty neat. Of course, as always, I was impressed 
more by watching the Alan Kay presentation videos like of drawing a fish 
in 2D and having software make it 3D and swim away than by using it myself.
   http://video.google.com/videoplay?docid=-9055536763288165825
Ignoring some walkbacks and exceptions when starting some of the demos, 
par for the course for my experience Squeaking, what I am left with is the 
same feeling I get when I watch pretty good 3D modeling of people -- which 
is sometimes a bit disconcerting (in a bad way). :-)

To explain, when you see cartoons of people, or mechanically rendered 
sprites of people with no serious attempts at skin texture or hair luster, 
you think, wow this is cool, and it is fun to look at. In my mind, that is 
something like using 2D apps or the command line. It does cool things its 
own way, and you can respect that. You get the immediacy people here talk 
about, and having no (or few) expectations about what it should do base 
don reality, nothing feels wrong (although it may still be confusing). 
But, when you look at images of people rendered in 3D that is pretty good 
(say 99%), they often look like corpses, because they are good enough to 
set in motion a whole bunch of reality based expectations we have for how 
other people should look, while not meeting them. Slightly drab hair? 
Maybe they are sick? Skin that looks like rubber? A sign of death. For 
more on this, see:
   "Realistic Human Graphics Look Creepy"
   http://games.slashdot.org/article.pl?sid=04/06/10/1327236
   http://www.slate.com/id/2102086 [article discussed]
So, by analogy, when you make fairly realistic 3D environments, but not 
100% realistic, you may be worse off for trying, because you raise 
expectations you can not fulfill, and the differences make people 
unconsciously feel uneasy, creepy, or frustrated. To be clear, I'm trying 
to make an analogy here; Croquet as a 1.0 beta demo does not attempt 
realistic human avatars, just a silly bunny rabbit avatar which looks 
cute. My point is about the 3D world aspect versus the real world.

So, in this case, with Croquet and 3D, perhaps more realism is actually a 
worse experience. And perhaps that unconsciously drives some of Alan Kay's 
interest in better 3D rendering? Yes, in theory you can get really good, 
but until you get there (when? 2020? 2040?), the results are sometimes 
almost more disappointing the closer you get to realism. I think Croquet 
may be facing that in the 3D realm. It activates expectations, like moving 
in 3D, but then you are confronted with how awkward it is to use the mouse 
to virtually "walk". You see a cube of blocks that invites you to take 
one, but when you put it back, there is no gravity to make it drop back 
into place, so it just oddly floats there. A slip of the mouse and the 
rabbit falls off the green carpet, to where? And it takes a bit of 
slogging to get back to anywhere interesting. I can see portals, but I 
can't shortcut click to them; I need to proceed slowly to them, and if I 
could click, and I suppose there is some trick perhaps, then I break the 
experience.

Obviously, specific popular 3D games solve many of these problems within 
the game in a fun "suspension of disbelief" way, and can be entertaining 
for twenty hours or so, and even leave you wanting more, e.g. a recent 
favorite of ours:
    "Beyond Good and Evil"
    http://www.gamespot.com/ps2/adventure/beyondgoodevil/
but, they do not seek to be the comprehensive life-time-of-use experiences 
that Croquet is implicitly claiming to be for right now (or at least, soon).

So, I wonder if better 3D graphics will really solve the problem in the 
near future. Short of Sutherland's "The Ultimate Display" (same as the 
Star Trek Holodeck), 3D worlds can be pretty dissatisfying or unfulfilling 
by themselves (ignoring their use as settings for games) if for no other 
reason (even if 100% visually realistic) than lack of force feedback or 
smell or air movement. Now, I'll say they can be useful, just like 2D 
white boards are, or conference calls are, and they can be fun (like many 
people find 3D games fun), but, ultimately, aside from any addicting game 
like aspects ("Evercrack") the 3D aspect by itself isn't a long term win 
(and it seems like the implicit notion of the Croquet work is that Croquet 
will be where we all spend most of our computer time). And the closer 
Croquet or similar systems get to reality, in some sense the more 
disappointing they are (up until we have the Holodeck or direct neural 
stimulation or something like that). Better to be in reality, I think. And 
stick with 2D or 3D graphics geared more towards efficient creation and 
collaboration than semi-realistic virtual creation and collaboration.

There's another thing that bothers me with the 3D world approach, and that 
is, it tends to run counter to the notion of moving fluidly between levels 
of abstraction, where you can see multiple representations of the same 
data. Our Garden Simulator (circa 1997) http://www.gardenwithinsight.com/ 
[See the second picture from the top on the right] tried to lead kids (or 
adults) from working in a relatively non-abstract garden setting onwards 
to using a level of abstraction using a numerical and graphical browser to 
visualize current state and change it, and then from that on to using 
graphs to visualize state over time, and so moving to higher levels of 
abstraction at each level. You could do that in a 3D Croquet world, say, 
by havinga 3D garden and a sheet of virtual graph paper, but it seems to 
me the 3D world is getting in the way a bit somehow, when you could just 
as well have a flat 2D window on your screen with a graph next to a 3D 
widnow of the garden. Granted, having a separate window for a 2D thing 
violates the paradigm Croquet is working towards, where multiple people 
can see what each other are looking at, so perhaps I need to understand 
more if that is really compelling and useful. But, on the other hand, even 
knowing where an avatar is pointing can't tell you what someone is 
thinking about. One big value of computers is that they can provide 
alternative ways to do things and look at things than is possible in the 
"real world". [One reason command line diehards like the command line so 
much is it makes some things easier to do with a mini-language than with a 
2D graphical interface, like change a bunch of files at once.] So, while 
the 3D Croquet interface does not demand giving up various levels of 
abstraction, it would seem to me it sort of encourages it. But that is not 
an opinion from using it much in practice, so perhaps in practice may be 
different.

Now this isn't to dismiss Croquet as a valuable experiment or as 
innovation. It's a good thing to have tried. And to keep trying with. And 
Python as a platform may well benefit from having some of this technology. 
It's just to consider it in the light of lessons learned and where to go 
next (for me or Python)?

But then you are left with the question -- how should people of varying 
abilities best interact with the computer in general and for various 
tasks. And, while I can see the value in a Croquet or ActiveWorlds 3D 
approach in some situations (I can see the potential value of being able 
to see where others are looking in the virtual world when collaborating, 
for example), I think there remains a lot of value in other interface 
paradigms, including both plain 2D widgets and also using a 3D window 
surrounded by 2D controls. (Obviously, whether OpenGL might render all 
that 2D stuff as well as the 3D stuff is just an implementation point in 
some sense.) So, in looking at the strengths and weaknesses of the 
Squeak/Croquet hybrid, derived from Self's Morphic and 2D collaborative 
model (and other things), I am again back to thinking that supporting 
collaboration in a 2D space (and ideally using prototypes) is potentially 
still a very useful thing, and a valuable first step. And so are any other 
approaches towards providing the option of doing development with Python 
in a way more like development under Smalltalk. And when six years ago I 
first brought up Squeak here, it was before Croquet, and in the context of 
these basic thing, plus some 2D learning applications built on top of them 
(more eToy-ish and HyperCard-ish and Virtual-Robot-programming-ish)

Anyway, having used Smalltalk for years (and ZetaLisp+Flavors before 
that), I am still confronted on a daily basis with the knowledge that it 
is productive and fun and empowering to develop with the level of 
interactivity Smalltalk (or the Symbolics) provides as an environment, and 
no Python IDE I have tried can deliver that (parts yes, the whole thing, 
no). Yet, I am also left with the reality that Python has gained 
acceptance because it is closer to C and BASIC in appearance, and because 
of its ability to play nice with other systems (especially ones written in 
C, or now, Java), as well as other factors, including that the license 
works out well for today's economic structures. So, on the one hand, I 
know what is possible, but on the other, I find myself often not able to 
make use of those systems in practice, which is what drives my interest on 
making such additions to Python more than anything.

> Incidentally, I just bought Civilization IV for my daughter [1], so we
> could give my wife's new computer a workout in the newly rented
> workspace [2], and she (my daughter) noticed right away that it
> contains Python bindings of some kind.  I haven't researched this yet,
> but I do find it exciting that a high powered game engine would make
> Python a part of its commercial front end, even mentioning Python on
> the box.

Your point is exactly what gives me pause about the Squeak / Croquet 
approach, and why Python has had more widespread commercial success. 
Scripting such things is just left out as an encouraged possibility with 
Squeak / Croquet (anything is possible with Squeak of course; it's a 
matter of focus and clutter). Squeak and Croquet are, as has been said 
here, sort of anti-collaborative. Which is ironic, since the whole point 
of Croquet is to be collaborative. [That was brought up years ago on this 
list.] Or perhaps, collaborative only on Croquet's terms? I liked your(?) 
proposal a way back on how what we need are standards for communicating 
between virtual world interfaces, so they could be implemented in various 
ways. Still, as Alan Kay has said, "any standard of more than three lines 
is ambiguous", and so you really need at least reference implementations, 
which Croquet is.

Yet, having said that, I am also thinking that given Python's success as 
gluing things together, and how all GUI toolkits are somewhat closed 
systems, see for example:
   "Why Gtk/Qt/WxWidgets... are bad"
   http://www.pygame.org/wiki/gui
I don't think it is unreasonable to argue for making another widget set 
(perhaps heavily copied from an existing one, like the pure Python on SDL 
OcempGUI)
   http://www.pygame.org/projects/9/125/
if there is a compelling and overwhelming reason to in terms of creating a 
good learning or developing environment in Python supporting a different 
paradigm of development ("modeless" versus "edit/run", and 
"prototype-oriented" instead of  "class-oriented"). That system can still 
be used to call existing (non GUI) libraries through Python. I'm not 
specifically making that argument right now, just saying, I think one 
could make it. For example, my very first Prototype proof of concept used 
TK widgets which were inherited from by prototypes. But I found when I 
copied one, that the widget was not copied, since internally two 
prototypes both point to the same proxied TK widget (as it was not 
copied). That's the sort of problem a pure Python solution might work 
around better (where a copied prototype would be a different GUI object). 
Not to say one might not be able to clone the TK widget, or a wx widget, 
just that it is more machinery, and perhaps some other unknown 
difficulties may exist in retrieving state from live widgets implemented 
in C/C++. But it is still hard to look at all the nice widgets in, say, 
the latest wx demo and think there is any point to writing yet another 
widget set... With all that entails...

Incidentally, I spent some time with the latest Debian versions of 
PythonCard and found a few issues from the standpoint of my using it. One 
is the paradigm -- mostly edit and run. Yes, you can change widget 
information while it is running, but that does not seem how it is set up. 
(HyperCard had a run/edit model too). Also, under GNU/Linux at least, you 
could not drag a button or list after you placed it -- they absorbed the 
clicks. Other components could be dragged. So, an inconsistency. Not sure 
if this is easily fixable with live wx components. In any case, that 
paradigm mismatch issue is potentially a large one.

--Paul Fernhout

From andre.roberge at gmail.com  Mon May 15 05:56:44 2006
From: andre.roberge at gmail.com (Andre Roberge)
Date: Mon, 15 May 2006 00:56:44 -0300
Subject: [Edu-sig] An engine to navigate between lessons
In-Reply-To: <4467E711.8080704@luc.edu>
References: <28855600.1147613361435.JavaMail.root@blb34.blogger.com>
	<7528bcdd0605140955o47cb768fw20f24663d2052ccb@mail.gmail.com>
	
	<7528bcdd0605141418m248037dex61a708677d4eba30@mail.gmail.com>
	
	<7528bcdd0605141815q2665207ds1df26e1a248bc3de@mail.gmail.com>
	<4467E711.8080704@luc.edu>
Message-ID: <7528bcdd0605142056u1809b793vbac83bf33029f992@mail.gmail.com>

On 5/14/06, Andrew Harrington  wrote:
>
> Navigating Between Lessons
>
> I have been reading the discussion and trying the prototypes for Python
> content delivery with great excitement.  On seeing how well you were
> doing on the content delivery, my imagination took off and I wrote down
> a whole bunch of brainstorming ideas below on an important independent
> aspect of an interactive learning environment.  Just tonight the "Only
> Python" thread touched on the area I have been thinking about with the
> idea of choosing what comes next after evaluating code in the Crunchy
> Frog.


[snip - snip - snip     lots of interesting material cut out.]

There were a lot of great ideas expressed in this brainstorming tsunami.  I
will latch onto a single theme.

For this to work, we need tutorials "snippets" ... lots of them.  I don't
think we need to worry too much at this point about complex links between
them, nor about the "syntax" required for those links.  I believe this is
going to be the easy part ... after enough tutorial snippets are written.
If it is web-based, the whole machinery pretty much already exists. One way
might be to embed keywords, including "difficulty ranking", inside tutorials
and use a search engine to decide where to go next.  Or, rather than using a
search engine, a "mind map" type of visual index can be created, with some
automatic updating whenever a new tutorial snippet is added, or a keyword is
added to that tutorial.  A variation on the them is that keywords inside a
given tutorial could be given some relative weighting factor.

Regardless of the chosen method ... lots of tutorials will be needed.  Until
then, I think that trying to come up with the ideal method to link them is
probably pointless; a case of premature optimization....

Andr?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20060515/222e9557/attachment.htm 

From kirby.urner at gmail.com  Mon May 15 07:05:31 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Sun, 14 May 2006 22:05:31 -0700
Subject: [Edu-sig] PySqueak: More on Croquet and 3D (was: Just ran...)
In-Reply-To: <4467F1EF.7010609@kurtz-fernhout.com>
References: 
	<4467345D.1060902@kurtz-fernhout.com>
	
	<4467F1EF.7010609@kurtz-fernhout.com>
Message-ID: 

Hi Paul --

You bring up a lot of important issues, I think the main one being:
how real do we really need it to be?  And leading up to that:  what
parameters are we talking about, when measuring the degree of realism?

I think an important language game to hold in mind as relevant is that
of chess.  The strategies don't change just because the pieces get
more detailed and animated.  P-K4 is still P-K4, even if the King's
lip is seen to quiver (hey, that looks like Johnny Depp!).

So in some sense all that texturing is extraneous in chess.  And yet
artisans lovingly carve chess sets out of every material (or build
them in OpenGL), using a vast assortment of designs.  Why?  Because
there's an artistic dimension orthogonal to the ostensive goal of the
game (to checkmate your opponent).

I get lost in this orthogonal dimension playing multi-user Quake or
Doom.  I'll just start admiring the artwork, smiling at all the
skillfully rendered skulls, nevermind the loser pumping me full of
bullets just now.

They say chess is a war game, and this spectrum between spare
iconography, versus vividly detailed scenes, is played out in the
military sphere big time.  Battlemaps, perhaps laid out as tiles,
perhaps hexagonal, contrast with a more on-the-ground first person
presence, sighting down the barrel of a gun or whatever.

Computer games will often emulate both aesthetics, as does ordinary
fiction.  We're accustomed to a mix of first and third person.

When it comes to highly detailed renderings, keep in mind why computer
games always seem tackier, less realistic, than state of the art
computer-generated movies:  the latter have all the CPU time they need
for each and every frame whereas the former have to keep a human
player entertained in real time, a whole different ball game.

Sustaining a high enough frame rate is what applications like Croquet
and Civ IV have to manage (many per second), whereas frames of 'Shrek'
might each take an hour in some rendering farm.  It's like the
difference between having hours to rehearse, versus spontaneous
improv.  Which isn't to say the skill sets aren't overlapping.
Practiced actors are also better at improv on average.

Anyway, I think the degree of realism needed, and in what dimensions,
is very application-specific.  That's why it's dangerous for the OS to
weigh in too heavily with a graphical view.

I like the stronger dichotomy between the GUI and kernel in Linux.
Windows users get confused by this, thinking GUI and OS must be
synonymous.

For the same reason, I like it that Python-the-language isn't too
vested in any one GUI solution.  It's a lexical controller of an
abstract model, via some API, not a view.  I think we should keep it
that way.  We're not trying to come up with the one set of graphical
motifs that "defines Python" -- because Python is ultimately lexical,
not graphical.

Python's "look and feel" has to do with syntax, not the shape or shade
of the widgets.  Python isn't Java, and no, we don't need our own
version of Swing.

So the degree and type of realism is application specific, is not
defined by the OS, is not defined by Python.  Python, like the OS, is
fairly agnostic about the user's world, its look and feel.

I don't imagine oil executives want cartoony avatars on screen, but
having all present gaze upon a shared view of some new drilling area,
complete with high def representations of rigs, pipelines (current and
projected), equipment and crews, makes the meeting more effective and
productive.

Oil execs are more like generals pouring over a battle map.  Their
vista is more game-like than ultra real, although shifting to overhead
photography ala Google Earth is always an option.

Kirby

PS:  I'm posting from my borrowed Edubuntu box for a change.  Dave
Fabik (appears in my blogs) lent me this Buffalo ethernet converter,
which goes from wireless to a regular ethernet card.  It's browser
configured.  This way, you don't need to mess with some PCI wireless
card or other gizmo needing a Linux-specific driver, provided your
eth0 NIC is already operational.

From aharrin at luc.edu  Tue May 16 22:31:35 2006
From: aharrin at luc.edu (Andrew Harrington)
Date: Tue, 16 May 2006 15:31:35 -0500
Subject: [Edu-sig] testing interactive loops
Message-ID: <446A36A7.5000102@luc.edu>

We have been discussing testing in tutorials with doctest. 
There is one place that does not work, I think:  testing an interactive 
loop, which is a construction I teach in introductory programming.

It appears that doctest cannot handle interactive input.  I would still 
like to be able to illustrate a session with interactive input and 
explicit output at the end, and check it automatically.

If you just do input redirection and compare the actual output to the 
desired input, you get messed up because the input is not echoed when 
you redirect from a file.
 
The following does not work, but is the idea you want, to force the echo 
when stdin become a file:

orig_raw_input = raw_input

def raw_input_echo(prompt=""):
    s = orig_raw_input(prompt)
    print s
    return s

raw_input = raw_input_echo

def input_echo(prompt=""):
    return eval(raw_input(prompt))

This fails because it makes raw_input a global for the current module, 
but not a built_in, so it fails when you import and use a module using  
raw_input.
 
I guess we could make it work in little code fragment tests, where you 
append the user's fragment to the code above, in the same module, but it 
is not a general solution.

Is there any better way to do this?

A kludge for tutorial doc tests would be to mark the prompt strings 
somehow in the tutorial source, for instance making it always end with 
:: or ?? so the test string can be parsed to find the responses that 
come after the prompts, and put them in the input file and not in the 
output file.  For example, the test string
... Sum numbers!
... Enter a number (or 0 to quit):: 3
... Enter a number (or 0 to quit):: 4
... Enter a number (or 0 to quit):: 8
... Enter a number (or 0 to quit):: 0
... The sum is 15!

might be processed for web display in the tutorial undoubling the ::

... Sum numbers!
... Enter a number (or 0 to quit): 3
... Enter a number (or 0 to quit): 4
... Enter a number (or 0 to quit): 8
... Enter a number (or 0 to quit): 0
... The sum is 15!

and the tutorial parser would also generate an input file
3
4
8
0

and output file

Sum numbers!
Enter a number (or 0 to quit):
Enter a number (or 0 to quit):
Enter a number (or 0 to quit):
Enter a number (or 0 to quit):
The sum is 15!

Then run the code with redirection and compare the desired and actual 
output.  There still is the issue of the program hanging with the given 
input ... 

How does regular doctest deal with infinite loops or waiting for 
nonexistent keyboard input?

Better ideas?

-- 
  Andrew N. Harrington
  Computer Science Department      Undergraduate Program Director
  Loyola University Chicago        http://www.cs.luc.edu/~anh
  512B Lewis Towers (office)       Office Phone: 312-915-7982
  Snail mail to Lewis Towers 416   Dept. Fax:    312-915-7998
  820 North Michigan Avenue        aharrin at luc.edu
  Chicago, Illinois 60611          


From andre.roberge at gmail.com  Tue May 16 23:14:20 2006
From: andre.roberge at gmail.com (Andre Roberge)
Date: Tue, 16 May 2006 18:14:20 -0300
Subject: [Edu-sig] testing interactive loops
In-Reply-To: <446A36A7.5000102@luc.edu>
References: <446A36A7.5000102@luc.edu>
Message-ID: <7528bcdd0605161414t191a0a65i745dd0d4be2c74da@mail.gmail.com>

On 5/16/06, Andrew Harrington  wrote:
>
> We have been discussing testing in tutorials with doctest.
> There is one place that does not work, I think:  testing an interactive
> loop, which is a construction I teach in introductory programming.
>
> It appears that doctest cannot handle interactive input.  I would still
> like to be able to illustrate a session with interactive input and
> explicit output at the end, and check it automatically.
>
> If you just do input redirection and compare the actual output to the
> desired input, you get messed up because the input is not echoed when
> you redirect from a file.
>
> The following does not work, but is the idea you want, to force the echo
> when stdin become a file:
>
> orig_raw_input = raw_input
>
> def raw_input_echo(prompt=""):
>     s = orig_raw_input(prompt)
>     print s
>     return s
>
> raw_input = raw_input_echo
>
> def input_echo(prompt=""):
>     return eval(raw_input(prompt))
>
> This fails because it makes raw_input a global for the current module,
> but not a built_in, so it fails when you import and use a module using
> raw_input.


How about:  (something totally untested)
import ah  # module named after you :-)
ah.raw_input = raw_input_echo

And then you run your tests?...

Andr?

I guess we could make it work in little code fragment tests, where you
> append the user's fragment to the code above, in the same module, but it
> is not a general solution.
>
> Is there any better way to do this?
>
> A kludge for tutorial doc tests would be to mark the prompt strings
> somehow in the tutorial source, for instance making it always end with
> :: or ?? so the test string can be parsed to find the responses that
> come after the prompts, and put them in the input file and not in the
> output file.  For example, the test string
> ... Sum numbers!
> ... Enter a number (or 0 to quit):: 3
> ... Enter a number (or 0 to quit):: 4
> ... Enter a number (or 0 to quit):: 8
> ... Enter a number (or 0 to quit):: 0
> ... The sum is 15!
>
> might be processed for web display in the tutorial undoubling the ::
>
> ... Sum numbers!
> ... Enter a number (or 0 to quit): 3
> ... Enter a number (or 0 to quit): 4
> ... Enter a number (or 0 to quit): 8
> ... Enter a number (or 0 to quit): 0
> ... The sum is 15!
>
> and the tutorial parser would also generate an input file
> 3
> 4
> 8
> 0
>
> and output file
>
> Sum numbers!
> Enter a number (or 0 to quit):
> Enter a number (or 0 to quit):
> Enter a number (or 0 to quit):
> Enter a number (or 0 to quit):
> The sum is 15!
>
> Then run the code with redirection and compare the desired and actual
> output.  There still is the issue of the program hanging with the given
> input ...
>
> How does regular doctest deal with infinite loops or waiting for
> nonexistent keyboard input?


??


Better ideas?
>
> --
>   Andrew N. Harrington
>   Computer Science Department      Undergraduate Program Director
>   Loyola University Chicago        http://www.cs.luc.edu/~anh
>   512B Lewis Towers (office)       Office Phone: 312-915-7982
>   Snail mail to Lewis Towers 416   Dept. Fax:    312-915-7998
>   820 North Michigan Avenue        aharrin at luc.edu
>   Chicago, Illinois 60611
>
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20060516/b00fdeb0/attachment.html 

From andre.roberge at gmail.com  Tue May 16 23:16:30 2006
From: andre.roberge at gmail.com (Andre Roberge)
Date: Tue, 16 May 2006 18:16:30 -0300
Subject: [Edu-sig] testing interactive loops
In-Reply-To: <446A36A7.5000102@luc.edu>
References: <446A36A7.5000102@luc.edu>
Message-ID: <7528bcdd0605161416i22d5a6b3t79337b3e1dbe9069@mail.gmail.com>

On 5/16/06, Andrew Harrington  wrote:
>
> We have been discussing testing in tutorials with doctest.
> There is one place that does not work, I think:  testing an interactive
> loop, which is a construction I teach in introductory programming.
>
> It appears that doctest cannot handle interactive input.  I would still
> like to be able to illustrate a session with interactive input and
> explicit output at the end, and check it automatically.
>
> Would this help?

http://mail.python.org/pipermail/python-list/2003-June/170627.html

Andr?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20060516/f2234079/attachment.htm 

From ianb at colorstudy.com  Wed May 17 04:40:16 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Tue, 16 May 2006 21:40:16 -0500
Subject: [Edu-sig] testing interactive loops
In-Reply-To: <446A36A7.5000102@luc.edu>
References: <446A36A7.5000102@luc.edu>
Message-ID: <446A8D10.2020500@colorstudy.com>

Andrew Harrington wrote:
> We have been discussing testing in tutorials with doctest. 
> There is one place that does not work, I think:  testing an interactive 
> loop, which is a construction I teach in introductory programming.
> 
> It appears that doctest cannot handle interactive input.  I would still 
> like to be able to illustrate a session with interactive input and 
> explicit output at the end, and check it automatically.
> 
> If you just do input redirection and compare the actual output to the 
> desired input, you get messed up because the input is not echoed when 
> you redirect from a file.
>  
> The following does not work, but is the idea you want, to force the echo 
> when stdin become a file:
> 
> orig_raw_input = raw_input
> 
> def raw_input_echo(prompt=""):
>     s = orig_raw_input(prompt)
>     print s
>     return s
> 
> raw_input = raw_input_echo
> 
> def input_echo(prompt=""):
>     return eval(raw_input(prompt))

import __builtin__
__builtin__.raw_input = raw_input

I'm pretty sure __builtins__ (that is automatically available 
everywhere) can't be updated like this, except from the __main__ module 
(where it is the same as __builtin__).  This can be confusing, because 
something will work at the interactive prompt or when run as a script, 
but won't work elsewhere.  But anyway, use __builtin__ and you're good.

-- 
Ian Bicking  |  ianb at colorstudy.com  |  http://blog.ianbicking.org

From pdfernhout at kurtz-fernhout.com  Wed May 17 14:38:08 2006
From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout)
Date: Wed, 17 May 2006 08:38:08 -0400
Subject: [Edu-sig] PySqueak: More on Croquet and 3D
In-Reply-To: 
References: 	<4467345D.1060902@kurtz-fernhout.com>		<4467F1EF.7010609@kurtz-fernhout.com>
	
Message-ID: <446B1930.8060902@kurtz-fernhout.com>

kirby urner wrote:
> Computer games will often emulate both aesthetics, as does ordinary
> fiction.  We're accustomed to a mix of first and third person.

You put it perfectly.

And I think that is what bothers me about Croquet in a sense as a proposal 
for "the" interface (especially for kids). The Croquet approach chooses to 
focus all interaction with the system through a first person 3D world on 
the computer display, with third person applications perhaps within that 
(e.g. a simulated sheet of 2D graph paper in that 3D world). I am more 
accustomed to think of the computer as displaying "third person" 
information, and then sometimes I'm willing to suspend disbelief for a 
first person interface within a window on that third person desktop. Even 
if the window takes up the entire screen (or all screens :-), I know the 
third person perspective lies underneath it if I stop that application. 
Ignoring the R&D aspects of Croquet (it's a good effort, breaks new 
ground, etc.), right now, I don't think computers (and interface 
technology) are not going to be close enough to 100% reality to make it 
worthwhile to channel all our interactions with them *first* through a 
first person 3D view. Certainly, if we get the Holodeck (with smell and 
force feedback) I'll revise that opinion. :-) And so also, from a 
perspective of priorities of making Squeak-like or Self-like things happen 
using Python in a learning (or developer) context, I think the Croquet 
aspects are less important than the interactive 2D tools aspects.

By the way, the seventeenth proof of concept of Prototypes in Python with 
the rudiments of a tree browser for 2D Morphs (though the browser is in wx):
http://svn.sourceforge.net/viewcvs.cgi/patapata/PataPata/proof_of_concept_017.py?view=markup

> Anyway, I think the degree of realism needed, and in what dimensions,
> is very application-specific.  That's why it's dangerous for the OS to
> weigh in too heavily with a graphical view.
 > [snip]
> I don't imagine oil executives want cartoony avatars on screen, but
> having all present gaze upon a shared view of some new drilling area,
> complete with high def representations of rigs, pipelines (current and
> projected), equipment and crews, makes the meeting more effective and
> productive.

You're absolutely right here. I think 3D is a great thing for visualizing 
data to understand issues and help solve problems, and a great way to 
communicate whatever the 3D representation chosen (realistic to whatever 
degree or even totally schematic or even mathematically abstract). And I 
can even see the value of ActiveWorlds type 3D with avatars for occasional 
meeting or even specific projects. To be clear, and to agree here, I have 
nothing against 3D. I was playing with VTK and the Python bindings for it 
the other day as on possibility for an underlying toolkit for a PySqueak, 
and can see the real value of it for looking at scientific data in general 
using Python. And I can see further how working in 3D could be very 
motivating to learn programming (if the package makes that easy to do, 
such as VPython or Alice attempts). And I think Croquet is a wonderful 
attempt to make it easy to do 3D collaborative applications. But, in 
considering Croquet as the evolution of Squeak as a kids programming 
environment I see an implicit intent based on my interpretation of Alan 
Kay's intent (perhaps in error?) that Croquet is what we should all use 
all the time when we are at the computer. I think that implicit intent is 
what bothers me, because, perhaps conditioned by experience (?), I think 
approaching the computer (as it exist now and for the next ten to twenty 
years) expecting a third person experience is better (i.e. more flexible, 
less disappointing, more effective for most tasks) than approaching it 
expecting a first person experience (where that first person experience 
will be missing things for the foreseeable future). Anyway, a 
philosophical point of interface design for me to muse over some more.

--Paul Fernhout

From kirby.urner at gmail.com  Wed May 17 19:23:00 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Wed, 17 May 2006 10:23:00 -0700
Subject: [Edu-sig] PySqueak: More on Croquet and 3D
In-Reply-To: <446B1930.8060902@kurtz-fernhout.com>
References: 
	<4467345D.1060902@kurtz-fernhout.com>
	
	<4467F1EF.7010609@kurtz-fernhout.com>
	
	<446B1930.8060902@kurtz-fernhout.com>
Message-ID: 

On 5/17/06, Paul D. Fernhout  wrote:

<>

> ground, etc.), right now, I don't think computers (and interface
> technology) are not going to be close enough to 100% reality to make it
> worthwhile to channel all our interactions with them *first* through a
> first person 3D view.

I tend to agree with all of the above.

However, between Croquet and a completely flat GUI, there's a
spectrum, and we're seeing signs of Cartesian 3Dness creeping in, but
not all that overwhelmingly, e.g. six desktops become the faces of a
cube, but you only zoom out and rotate the cube when flipping to a
different desktop (doesn't happen all that often unless you're by
nature frenetic):

http://worldgame.blogspot.com/2006/05/blabbing-on-edu-sig.html

Even more subtly, windows have been garnering depth cues for years,
plus gradually straying from the purely rectangular:

http://worldgame.blogspot.com/2004/12/interface-designs.html

(I've this curvilinear motif on CBS News too -- TV and computer screen
aesthetics interpenetrate in large degree).

> You're absolutely right here. I think 3D is a great thing for visualizing
> data to understand issues and help solve problems, and a great way to
> communicate whatever the 3D representation chosen (realistic to whatever
> degree or even totally schematic or even mathematically abstract). And I

Games!  World Game is less apologetic for using the word "game"
because it's more about happy stuff than what got plotted on the old
War Game boards.  We're more light-hearted in our approach to global
simulations, though just as into cross-checking and verifying.
Vigilance against sloppy scholarship remains of paramount importance.

> attempt to make it easy to do 3D collaborative applications. But, in
> considering Croquet as the evolution of Squeak as a kids programming
> environment I see an implicit intent based on my interpretation of Alan
> Kay's intent (perhaps in error?) that Croquet is what we should all use
> all the time when we are at the computer. I think that implicit intent is

That will never happen, except sure, maybe *some* people will eat
their own dog food in this regard.  In general though, people are too
curious to ever alight on one generic omniembracing containment
system.  That's what reality is for.  Within reality, all GUIs are
special case.

That being said, let's use Croquet sometimes, why the hell not?  I'd
especially like it on a much bigger screen with a projector, and with
less of an Alice in Wonderland flavor (I've already got Alice, the
computer game, which twists the scenario into something darker and
more gothic -- closer to Batman in flavor, and therefore more
comfortingly all-American in my book (but who wants something that
twisted for an interface? (we should at least be able to "skin"
Croquet in some dimensions, according to personal taste, if it really
purports to be more of an operating system and less of an
application))).

> what bothers me, because, perhaps conditioned by experience (?), I think
> approaching the computer (as it exist now and for the next ten to twenty
> years) expecting a third person experience is better (i.e. more flexible,
> less disappointing, more effective for most tasks) than approaching it
> expecting a first person experience (where that first person experience
> will be missing things for the foreseeable future). Anyway, a
> philosophical point of interface design for me to muse over some more.
>
> --Paul Fernhout

Some will experiment with other shapes of screen.  Imagine the
challenge of fitting a GUI to an hexagonal frame.  Very Klingon.  Very
Dymaxion.

Kirby

PS:  you're mentioned in my blog too by the way:
http://mybizmo.blogspot.com/2006/05/home-schooling.html

From vceder at canterburyschool.org  Thu May 18 04:26:27 2006
From: vceder at canterburyschool.org (Vern Ceder)
Date: Wed, 17 May 2006 22:26:27 -0400
Subject: [Edu-sig] Turtle.py patches accepted
Message-ID: <446BDB53.6050301@canterburyschool.org>

This is just a quick notification that several patches to turtle.py 
(originally mentioned here right after PyCon) have been committed to the 
2.5 alpha trunk. They were:

* docstrings added to methods (Toby Donaldson)

* added methods to control speed, window geometry and
window title. (Vern Ceder)

* added Turtle as alias for Pen - students can now
create Turtle objects (Toby Donaldson)

* default window now larger and centered (Vern Ceder)

* added done() function to start main event loop after
drawing (handy when running programs in IDLE) (Vern
Ceder/Chris Smith)

* fixed bug where filled polygons are always lowered (Atanas
Radenski)

* fixed bug in circle() method to use self._fullcircle
/ 4.0 instead of 90.0 to determine start (Chris Smith)

* removed several redundant assignments (Chris Smith)

* added second demo which uses new features (Gregor Lindl)

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

From pdfernhout at kurtz-fernhout.com  Thu May 18 23:04:15 2006
From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout)
Date: Thu, 18 May 2006 17:04:15 -0400
Subject: [Edu-sig] PySqueak: More on Croquet and 3D
In-Reply-To: 
References: 	<4467345D.1060902@kurtz-fernhout.com>		<4467F1EF.7010609@kurtz-fernhout.com>		<446B1930.8060902@kurtz-fernhout.com>
	
Message-ID: <446CE14F.2030902@kurtz-fernhout.com>

kirby urner wrote:
> That will never happen, except sure, maybe *some* people will eat
> their own dog food in this regard.  In general though, people are too
> curious to ever alight on one generic omniembracing containment
> system.  That's what reality is for.  Within reality, all GUIs are
> special case.

Good point. Funny thing is, as I think about it, that Croquet to some 
extent perhaps repeats the thought of the original Macintosh Desktop -- 
that is, give people a desktop they are comfortable with and they can 
easily use it. The problem is, that things didn't always do what people 
expected, and the desktop metaphor can be pretty limiting.

By the way, as I though about your use of "first person" (I) and "third 
person" (he/she/it) for interface types (exemplified by 3D shooter vs. 2d 
map with markers) I realized that for completeness one should consider 
"second person" (you) interfaces, which I would think would be more like 
conversations, e.g. ("Computer, you should really print out my reports, 
please." :-). [I have worked somewhat in the past on such speech driven 
second person interfaces.] Likely there might be other versions related to 
tense or indirect reporting of things. Some more ideas here:
   http://en.wikipedia.org/wiki/Grammatical_person
 From there: "The grammar of some languages divide the semantic space into 
more than three persons. The extra categories may be termed fourth person, 
fifth person, etc. Such terms are not absolute but can refer depending on 
context to any of several phenomena."

> That being said, let's use Croquet sometimes, why the hell not?  I'd
> especially like it on a much bigger screen with a projector, and with
> less of an Alice in Wonderland flavor (I've already got Alice, the
> computer game, which twists the scenario into something darker and
> more gothic -- closer to Batman in flavor, and therefore more
> comfortingly all-American in my book (but who wants something that
> twisted for an interface? (we should at least be able to "skin"
> Croquet in some dimensions, according to personal taste, if it really
> purports to be more of an operating system and less of an
> application))).

Interesting idea...

> Some will experiment with other shapes of screen.  Imagine the
> challenge of fitting a GUI to an hexagonal frame.  Very Klingon.  Very
> Dymaxion.

Definitely the promise of making systems you can "glue" together.

By the way, no hexagons yet, but this project
   http://sourceforge.net/projects/patapata
is up to "proof_of_concept_021.py"
http://svn.sourceforge.net/viewcvs.cgi/patapata/PataPata/proof_of_concept_021.py?view=markup
which finally has gotten to the point where I can edit what morphs do in a 
very limited sense. You have to put your code in like this:
   PrototypeMethod(self, "def grow(self): print 'grow changed'\n")
and you can only modify existing methods.

These proof of concepts have brought home hard one major language 
impedance mismatch issues trying to use Python to be like "Self" or 
"Smalltalk": Python is oriented around supply a function and then calling 
it, whereas Smalltalk and Self are oriented around message passing. Thus, 
implementing "doesNotUnderstand" is possible in Squeak/Self, as is 
executing code on simple accesses (e.g. "self spam"), whereas under Python 
I can't assume what someone retrieving a function or variable plans to do 
with it. That also leads to the issue of dynamically wrapping methods and 
the overhead for it in memory and computation in Python.

Also, I need to think through initialization better, because otherwise 
prototypes which are filling the role of classes have their lists or 
dictionaries shared across all instances, whereas I really want those per 
item. I have a workaround in place but I don't like it. And that gets back 
to a problem with my very first prototype using TK, where I copied a 
prototype which inherited from a TK widget, but the widget itself was not 
duplicated. I guess I could duplicate that widget as part of a special 
init or copy constructor. If I can manage that trick, then I could have a 
hope of embedding TK or wx widgets into a world of prototypes.

I've continued to look at other languages in terms of how the approach 
some of these issues, and came across this little idea:
   http://www.paulgraham.com/popular.html
""The best writing is rewriting," wrote E. B. White. Every good writer 
knows this, and it's true for software too. The most important part of 
design is redesign. Programming languages, especially, don't get 
redesigned enough. To write good software you must simultaneously keep two 
opposing ideas in your head. You need the young hacker's naive faith in 
his abilities, and at the same time the veteran's skepticism. You have to 
be able to think how hard can it be? with one half of your brain while 
thinking it will never work with the other. The trick is to realize that 
there's no real contradiction here. You want to be optimistic and 
skeptical about two different things. You have to be optimistic about the 
possibility of solving the problem, but skeptical about the value of 
whatever solution you've got so far. People who do good work often think 
that whatever they're working on is no good. Others see what they've done 
and are full of wonder, but the creator is full of worry. This pattern is 
no coincidence: it is the worry that made the work good. If you can keep 
hope and worry balanced, they will drive a project forward the same way 
your two legs drive a bicycle forward. In the first phase of the two-cycle 
innovation engine, you work furiously on some problem, inspired by your 
confidence that you'll be able to solve it. In the second phase, you look 
at what you've done in the cold light of morning, and see all its flaws 
very clearly. But as long as your critical spirit doesn't outweigh your 
hope, you'll be able to look at your admittedly incomplete system, and 
think, how hard can it be to get the rest of the way?, thereby continuing 
the cycle. It's tricky to keep the two forces balanced. In young hackers, 
optimism predominates. They produce something, are convinced it's great, 
and never improve it. In old hackers, skepticism predominates, and they 
won't even dare to take on ambitious projects. "

Anyway, I broke the versions out into separate incremental files so people 
could easily follow what I was doing and perhaps revisit assumptions at 
earlier points. I've reached the point through where for more complex 
prototypes it may be hard to keep them in one file (especially if I 
started testing writing and loading Python files to save widget state) and 
at that point I'd probably start using SVN in a more typical way. (And at 
some poitn I'll probably move all those files into a directory and those 
previous links may break, but the code shoudl still be findable from the 
main project SVN page.)
  http://svn.sourceforge.net/viewcvs.cgi/patapata/PataPata/

At this point, with a little handwaving about how easy 3D is in Python :-) 
I'm tempted to just do the politician's trick of declaring "victory" (at 
showing Python doing Self-like and Squeak-like and Morph-like things) and 
going home. :-) [Well I'm already at home, so that's just a turn of 
speech, but often good advice anyway. :-)]

Realistically, the last prototype is still quite a ways from where anyone 
would want to use it to do software development (and the inspector is 
still wx and not native), but it does show how (ignoring efficiency) one 
can create a graphical world of prototypes and interact with it 
dynamically using Python. So, it is a tiny fraction of 3D Alice in Python 
of almost ten years ago. :-)
http://www.cs.cmu.edu/~stage3/publications/95/journals/IEEEcomputer/CGandA/paper.html
You can see pessimism is outweighing optimism at this point in my mind. :-)

Anyway, what I can say that is good about it is that *if* people want to 
talk about or demonstrate prototype based languages using Python, this is 
a little example consisting of a single file (~20K) that is a starting 
point for discussion of "prototype vs. class-based" programming,

> PS:  you're mentioned in my blog too by the way:
> http://mybizmo.blogspot.com/2006/05/home-schooling.html

Thanks for the link. IMHO, the reality is that (almost) all learning is 
really learned originated, it is just that it sometimes also happens in 
the classroom. :-)

--Paul Fernhout

From kirby.urner at gmail.com  Fri May 19 00:07:45 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Thu, 18 May 2006 15:07:45 -0700
Subject: [Edu-sig] Refocusing on Capabilities (was PySqueak)
Message-ID: 

Good thinking Paul, about the balance between optimism and skepticism.
 We do need to revisit old designs, and admit their weaknesses.

USAers still seem in denial about their infrastructure.  A lot of it's
still good, but was meant to be maintained, not neglected.

My hope is that infusions of data rich content will help people feel
more in the driver's seat, in terms of at least tracking what's going
on.  Python-the-language is helping with this (at Google, other
places).

Then we'll need a lot more teams in the field, tackling specifics
(again, the overview versus 1st person motif, familiar from war game
simulations, and now I'm saying in world game as well).  2nd person
enters with this sense of being on a team (we collaborate).  Python
has a role to play here as well.

Perhaps we're somewhat off on a tangent in discussing simply the Dness
of the thing (2D vs. 3D vs. 4D or whatever).

Perhaps more to the point are the modes we access:

(1) a creative brainstorming mode, more playful and open to novelty

(2) a getting down to business, activist phase wherein we actually
implement and make happen

(3) an awareness-of-assets phase, an appreciation for what's already
at our disposal, what's already invented and downloadable and so on.

I summarize these as the BE, DO and HAVE modes or phases, and did an
early collage about that under the heading of general systems theory
(GST):

http://www.grunch.net/synergetics/gst1.html

In CS terms, we have design phase, coding phase, and legacy software
and hardware.  The legacy stuff needn't always be approached as
burdensome though -- that's not the creative attitude.  Good designs
recycle and reuse, have a role for retro.  FORTRAN still offers some
dynamite libraries.  We simply wrap them in our newer OO APIs.

The strength of Open Source is we allow, encourage and foment copying,
as the precursor to studying and improving.  We celebrate the
relevance of Having (over simply Being and Doing).

Anyway, when it comes to Python in Education, I like to think of the
ways in which Python might be able to amplify and improve one's
experience in all three of these modes.  Whether that involves 2D, 3D
or whatever-D aesthetics is a somewhat orthogonal and I dare say
somewhat irrelevant issue.

We want to get work done, and so we need to play, we need to make
happen, and we need to keep track and recycle.

Python has those capabilities:  it reads like pseudo-code and so is
suggestive and encouraging of playful exploration; in production
settings it generally does a reliable job of handling real world
responsibilities.  It may be in this last area (of Having) that Python
is currently weakest. Like, Perl's CPAN is the stronger HAVE
technology.

But I'm not despairing.  There's lots we can do ala the mythical
Vaults of Parnassus, to keep our vast and growing inventory of assets
accessible and relevant to future selves.

Kirby

From kirby.urner at gmail.com  Sun May 21 02:47:23 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Sat, 20 May 2006 17:47:23 -0700
Subject: [Edu-sig] Pythonic Mathematics (session 5)
Message-ID: 

For those curious, my fifth and final Pythonic Mathematics session for
Saturday Academy in Spring 2006 is written up here:

http://mathforum.org/kb/message.jspa?messageID=4726175

Kirby

From kirby.urner at gmail.com  Sun May 21 15:33:26 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Sun, 21 May 2006 06:33:26 -0700
Subject: [Edu-sig] More re Saturday Academy course
Message-ID: 

A useful aspect of mixing Python with some POV-Ray training, aside
from the immediate access to graphics, is a golden opportunity to go
over string substitution, especially using dictionary key arguments.

Here is a tiny namespace that outputs colored balls, randomly
positioned and sized.  In class, I asked for a hundred of 'em.  Note
that lottaspheres simply dumps to stdout (IDLE in this case).  Writing
to a file might be the more sophisticated way to go, but I'm focusing
on one feature at a time, and cut and paste works just fine for demo
purposes:

from random import randint

def somesphere():

    xyz = tuple([ randint(-5,5) for r in range(3) ])
    coords = "<%s, %s, %s>" % xyz
    radius = randint(1,4)/2.0
    color = ['Orange','Blue','Green','Yellow','Gold'][randint(0,4)]

    specs = {'theplace':coords, 'thecolor':color, 'theradius':radius }

    mysphere = """
sphere {
    %(theplace)s, %(theradius)s
    texture {
      pigment { color %(thecolor)s }
    }
}
    """ % specs

    return mysphere

def lottaspheres(n):
    for i in range(n):
        print somesphere()


Actually, the output of the above left something to be desired,
aesthetically.  With tweaking, more could be done.  Like, I'd suggest
smaller spheres.

Anyway, the point is it's easy to toss out any number of such tiny
functions, all aimed at saving typing in POV-Ray and giving us pretty
stuff to look at.  And one point of doing *that* is students see
string substitution in action.

On a related note, I see POV-Ray as an excellent vehicle for
introducing and/or revisiting XYZ coordinates as a topic.  The Z axis
is into the screen, with positive X to the right, Y up.  Simply
rendering three colorized axes, say from -5 to 5, and then
test-placing various objects to get a feel for things.

Important in ray tracing:  to locate the point the camera.

Somehow, our culture has devised these third person viewpoints that
disavow their first personhood, e.g. when you're looking at some
polyhedron in a math textbook, you're not usually encouraged to think
about the question "from where am I looking?"

Computer graphics, on the other hand, is refreshing in that it
acknowledges the relevance of viewpoint or vantage point (camera
location), even if the scene is quite devoid of persons.  In this
sense, we're closer to the world of movie directors.

Likewise, ray tracing encourages to think about the so-called
"secondary characteristics" of otherwise Platonic objects nesting in
some Cartesian-Fermatian XYZ space.  We think about color, texture,
reflectivity, shadows.

I like the interdisciplinary feel of this.

"Pure math" (which historically turns up its nose at such special case
details, or even graphics of any kind) is too confining and
restraining, especially when we're trying to develop sophisticated and
powerful imaginations in young people.

That's why we should be using more ray tracer and less chalkboard.
Beyond Flatland.

Kirby

From kirby.urner at gmail.com  Sun May 21 16:30:48 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Sun, 21 May 2006 07:30:48 -0700
Subject: [Edu-sig] More re Saturday Academy course
In-Reply-To: 
References: 
Message-ID: 

> Important in ray tracing:  to locate the point the camera.
>

...to locate and point the camera (I meant to type), com sa:

camera {
    location <3, 5, -30>
    look_at  <-2, 1,  2>
 }

And here's typical output from the aforementioned somesphere() function:

sphere {
    <0, -1, 2>, 1.0
    texture {
      pigment { color Orange }
    }
}

My more typical approach in CP4E is to develop a Gibbsian vector
class, complete with operator overloading, then feed vectors to a
POV-writer with a focus on three main features corresponding to
Euler's V + F = E + 2:  vertices, faces and edges.  In POV-Ray, these
would be spheres, polygons and cylinders.

However, there's no requirement that vector arithmetic be an early
focus.  String substition, perhaps coming from Madlibs, and now used
to develop scene description language, would prepare students for the
later vector-based POV-writer code.

Still later:  Quaternions (how vector algebra got started actually, by
Hamilton, until they were later subclassed and adapted by Gibbs and
Heaviside later on).  Herman Grassmann helped universalize the
concepts and now we have the Clifford Algebra branch in addition to
the more traditional Gibbsian and Hamiltonian.

All of these different math objects may be explored pythonically,
using the "maths as extensible type system" approach.

http://en.wikipedia.org/wiki/Exterior_algebra

Kirby

From pdfernhout at kurtz-fernhout.com  Tue May 23 06:47:36 2006
From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout)
Date: Tue, 23 May 2006 00:47:36 -0400
Subject: [Edu-sig] Refocusing on Capabilities (was PySqueak)
In-Reply-To: 
References: 
Message-ID: <447293E8.7030601@kurtz-fernhout.com>

Kirby-

All good points. And we definitely need a better infrastructure given 
continual population growth -- especially one doing more with less, and 
doing it in a more resilient and sustainable way. I think that is also one 
of the pushes towards prototypes in "Self" -- the Self authors describe an 
attempt to address the fragile base class problem and make software both 
more flexible and more resilient (as well as more consistent).
    http://en.wikipedia.org/wiki/Self_programming_language

And, along those lines, more updates on the PataPata (PySqueak) project:
   http://sourceforge.net/projects/patapata

There is now a screenshot of the 25th proof of concept at:
   http://sourceforge.net/project/screenshots.php?group_id=165910
That should give a sense of what the whole thing does so far as the demo 
is only one window (although there are also popup menus you can't see).

Note: Under Gnome, you need to change Window manager preferences so that 
ALT does not drag windows (choose the Windows key instead). I have not 
tested it under other platforms, though wx (2.6) should run on Mac and Win.

You may notice by looking in the browser (yellow part) of the screenshot 
that I made a design decision to implement multiple-inheritance (of 
traits) but using a list of name strings rather than direct pointers, so 
any prototype you want to use as a parent needs to be given a name under 
"world.worldGlobals[]". Personally, I find the most important part of 
programming to be documenting *intent*, and so I thought the explicit 
naming requirement was OK. I've always been dismayed at the potential of a 
Self-like approach to create a real mess otherwise. (Forth us another 
language system that fails at documenting intent too, though it does most 
everything else right.) These named prototypes take the place of classes, 
but without the class-side / instance-side divide of Smalltalk.

The twenty fifth proof of concept now can load and store Python source 
files of prototypes (essentially by just writing a "define_prototypes()" 
function and exec-ing it back in). There are some limits that embedded 
Python objects you want to store must implement a 
useful-for-reconstituting __repr__ string (though it does handle nested 
dicts and lists out of the box). You can finally add and remove prototype 
fields from the inspector, create new methods and edit them, and it now 
has an interactive shell plus some other polish. See the code at:
http://svn.sourceforge.net/viewcvs.cgi/patapata/PataPata/proof_of_concept_025.py?view=markup

An example of the Python source file it can write and read (demonstrating 
the idea discussed a couple weeks back of using Python source instead of 
pickle files to save widget state) is here:
http://svn.sourceforge.net/viewcvs.cgi/patapata/PataPata/some_output_prototypes_written_by_poc25.py?view=markup
You don't need it to run the P.O.C. 25 demo though; that is still 
self-contained. [This example file is missing a few world methods I added 
afterwards.]

The system is still limited to two widgets though (Morph and TextMorph). 
Adding more widgets is a bigger undertaking and realistically will likely 
entail splitting the prototype into multiple files, which I have been 
avoiding.

Also, functions defined in the interactive shell (as opposed to defined in 
a file or defined using the inspector) don't have source code available, 
which would be a problem when you save them. Not sure how to fix that 
easily without changing wx's shell.py. But that's not really what the 
shell is for as opposed to interactive testing or importing other Python 
files, so it's a minor problem for now. For now, best to stick to defining 
new prototype methods using the inspector or source files.

The system may finally be at the point where (in theory) one could use 
only the system to improve itself, though in practice messing with the 
wx-based GUI scaffolding by changing the main application source file 
would still often be easier. Everything is still in one Python file for 
ease of prototyping and people trying it, but at ~49K it's straining to 
break loose into various files and who knows what else. :-)  Anyway, I 
definitely feel it has reached the point where it is a useful tool for 
learning about prototype-based-programming in a Python context. Not my 
eventual goal, but a useful byproduct.

Amazing what is easily possible by building on top of Python and not 
getting sidetracked (as I usually do) by writing a new interpreter or 
messing with the syntax (at least, not at first. :-) Well, that and 
throwing performance and morph-loading-security to the winds. :-)
[It does point out the need for a Python VM with security flags one could 
set like Java has (e.g. can't write to most files, can't open most 
sockets, etc.), although I guess you could run under Jython to get some of 
that.]

Still no 3D yet, though. :-(

Say, Kirby, speaking of "data rich content", can you suggest any Bucky 
Fuller-ish or synergetics-type graphics or clip art under a 
free-as-in-freedom license somewhere on the web I could use to spice this 
demo up when I move beyond having everything in one file? Ideal would be 
graphics a demo could load from the web as a URL to keep everything in one 
file (though I probably should put them on another web server to be 
polite, though I don't expect anybody to really use it anytime soon). Even 
just graphics like the individual source items for the web page you linked to:
   http://www.grunch.net/synergetics/gst1.html
might be snazzy to just drag around as Morphs. Or perhaps I could try to 
use them to make a HyperCard-like stack with the proof-of-concept as a 
test and to motivate putting in related supporting features (including 
perhaps a Bitmap-from-URL-Morph and a Card-Morph and a 
Stack-Of-Cards-Morph). Also, if you have any pointers to 
free-as-in-freedom Bucky-related content I could throw in such a stack, 
that would be nice too. I'm mainly just looking for something that makes a 
nice demo with a dozen cards worth of interesting educational content and 
graphics. I could go with gardening (I've lots of stuff on that) but I 
thought Bucky stuff might be more fun right now.

--Paul Fernhout

kirby urner wrote:
> Good thinking Paul, about the balance between optimism and skepticism.
>  We do need to revisit old designs, and admit their weaknesses.
> 
> USAers still seem in denial about their infrastructure.  A lot of it's
> still good, but was meant to be maintained, not neglected.
> 
> My hope is that infusions of data rich content will help people feel
> more in the driver's seat, in terms of at least tracking what's going
> on.  Python-the-language is helping with this (at Google, other
> places).
 >
> [snip]
> 
> We want to get work done, and so we need to play, we need to make
> happen, and we need to keep track and recycle.
> 
> Python has those capabilities:  it reads like pseudo-code and so is
> suggestive and encouraging of playful exploration; in production
> settings it generally does a reliable job of handling real world
> responsibilities.  [snip]

From delza at livingcode.org  Tue May 23 07:02:21 2006
From: delza at livingcode.org (Dethe Elza)
Date: Mon, 22 May 2006 22:02:21 -0700
Subject: [Edu-sig] Refocusing on Capabilities (was PySqueak)
In-Reply-To: <447293E8.7030601@kurtz-fernhout.com>
References: 
	<447293E8.7030601@kurtz-fernhout.com>
Message-ID: <24d517dd0605222202o69175fffua2ff4d0bc0ab03@mail.gmail.com>

On 5/22/06, Paul D. Fernhout  wrote:
> Also, if you have any pointers to
> free-as-in-freedom Bucky-related content I could throw in such a stack,
> that would be nice too. I'm mainly just looking for something that makes a
> nice demo with a dozen cards worth of interesting educational content and
> graphics. I could go with gardening (I've lots of stuff on that) but I
> thought Bucky stuff might be more fun right now.

Hi Paul,

I have a feeling you're about to get more than you bargained for.
Kirby is a kind of Ground Zero for Bucky resources on the web--I knew
of him from my readings on Synergetics long before meeting up with him
in edu-sig. There is plenty of Bucky on the web to choose from,
although much (most) of it is copyrighted.  The magnum opus,
Synergetics, is available here:

http://www.rwgrayprojects.com/synergetics/toc/toc.html

While it is copyrighted, many of the ideas in it lend themselves to
software expressions. When I was reading it (on traditional pulped
trees) I felt like there should be an accompanying set of small
programs demonstrating the ideas.  Bucky expends a lot of text trying
to describe 3D animations in prose.

--Dethe

From kirby.urner at gmail.com  Tue May 23 07:08:49 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Mon, 22 May 2006 22:08:49 -0700
Subject: [Edu-sig] Refocusing on Capabilities (was PySqueak)
In-Reply-To: <447293E8.7030601@kurtz-fernhout.com>
References: 
	<447293E8.7030601@kurtz-fernhout.com>
Message-ID: 

> Say, Kirby, speaking of "data rich content", can you suggest any Bucky
> Fuller-ish or synergetics-type graphics or clip art under a
> free-as-in-freedom license somewhere on the web I could use to spice this
> demo up when I move beyond having everything in one file?

Click around in my websites.

A lot of what's in synergetics is generic concepts organized in
sometimes novel ways, but not owned in the sense the icosahedron is
not owned, nor the sphere packing lattice we call the CCP etc.

So often what's fun, given Python and a few tools, is to generate
one's own images (no permission required).

However, if you want already-ready images, there's lots at
grunch.net/synergetics.  If you have any questions about a specific
image, just sent me off-list email.  Joe Moore has a lot of images.
Plenty of other sources.  Fuller School is definitely data rich (huge
stash @ Stanford).

Kirby

From pdfernhout at kurtz-fernhout.com  Tue May 23 16:11:14 2006
From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout)
Date: Tue, 23 May 2006 10:11:14 -0400
Subject: [Edu-sig] Refocusing on Capabilities (was PySqueak)
In-Reply-To: 
References: 	<447293E8.7030601@kurtz-fernhout.com>
	
Message-ID: <44731802.5080809@kurtz-fernhout.com>

kirby urner wrote:
>>Say, Kirby, speaking of "data rich content", can you suggest any Bucky
>>Fuller-ish or synergetics-type graphics or clip art under a
>>free-as-in-freedom license somewhere on the web I could use to spice this
>>demo up when I move beyond having everything in one file?
> 
> Click around in my websites.
> 
> A lot of what's in synergetics is generic concepts organized in
> sometimes novel ways, but not owned in the sense the icosahedron is
> not owned, nor the sphere packing lattice we call the CCP etc.
> 
> So often what's fun, given Python and a few tools, is to generate
> one's own images (no permission required).

Excellent idea. And probably what I'll do if I go down that path. Thanks 
for the suggestion. Now just to get a three-D turtle going again in 
Python... :-)

> However, if you want already-ready images, there's lots at
> grunch.net/synergetics.  If you have any questions about a specific
> image, just sent me off-list email.  

Thanks for the generous offer; I may do that.

== a bit of a copyright and licensing rant follows, but it is not meant 
personally  ===

In practice, though, as a free software developer who dislikes paperwork, 
it's probably more work to ask (perhaps multiple times as new things are 
of interest) for permissions than it is worth, compared to, as you 
suggest, doing my own stuff programmatically (or otherwise).

In practice, I almost never think something is worth using enough to ask 
for permissions; I just don't use it and look for something else, or I 
even abandon the project.

I also would have to trust a longer copyright paper trail. This is not to 
suggest anything sleazy by anyone, just that it's easy in copyright issues 
for miscommunication or misinterpretations to arise as to what is 
permitted when someone other than the original author or copyright holder 
makes a formal statement. So what one person who knows the author or 
current owner thinks they can do safely often looks a lot less safe to 
someone else coming at things second or third hand and relying on indirect 
representations.

Looking for stuff that is already clearly licensed is generally just 
easier, like at:
   http://www.openclipart.org/
which links further to various other similar sites:
   http://www.openclipart.org/wiki/index.php/Similar_Projects
[No Bucky stuff I could find though.]
Googling on "free clipart" first leads me to commercial sites it seems. 
:-( Are there any other good free clip art sites people recommend for use 
for clip art for Python programs?

Or perhaps now that I think of it, Wikipedia could be a source:
   http://en.wikipedia.org/wiki/Buckminster_Fuller
There are two GFDL images on the Bucky page.
Or more broadly, lots of GFDL images here:
   http://en.wikipedia.org/wiki/Category:GFDL_images
Unfortunately the GFDL license is GPL-incompatible! I've already had words 
with Richard Stallman about this, :-) but so far I haven't been able to 
get him to acknowledge how evil GPL-incompatibility is for a content 
license (especially one the FSF promotes)! :-) From:
   http://en.wikipedia.org/wiki/GNU_Free_Documentation_License
"The GNU FDL is incompatible in both directions with the GPL: that is GNU 
FDL material cannot be put into GPL code and GPL code cannot be put into a 
GNU FDL manual." See also:
   "Why You Shouldn't Use the GNU FDL"
   http://home.twcny.rr.com/nerode/neroden/fdl.html
which suggests, among other things, just using the GPL instead for 
content. Ironically, this FSF page expounds on the problems with some 
Creative Commons licenses being GPL-incompatible,
     http://www.fsf.org/licensing/licenses/
but is strangely silent on GFDL/GPL incompatibility issues which IMHO are 
similar. I'm hoping that incompatibility gets fixed in later versions of 
the GPL or GFDL. I've already had it make impossible another project 
(building GPL-d simulations based on Wikipedia content).

I'm not sure yet on Python-license and GFDL content compatibility; I think 
they might work, except the GFDL would take precedence and might not 
really give permission to run the combined work?

I'm really picky about these licensing issues, because it is so easy to 
use something incorrectly and recently the formerly civil problem of 
copyright infringement in the USA has been turned into a criminal offense 
(felony), and though it is not yet often enforced, it is made easily 
enforceable by broad interpretations of what it means to make a profit 
from redistributing something.
   http://www.usdoj.gov/criminal/cybercrime/CFAleghist.htm
See also for example this slashdot article and also my comments here:
   http://yro.slashdot.org/article.pl?sid=05/11/13/1624200
So, best to stay on the safest ground when possible and when building 
stuff for others to use, and an example of the "chilling effect" of such 
copyright legislation on innovation in the USA (or, another 
"infrastructure" problem :-).

> Joe Moore has a lot of images.
> Plenty of other sources.  Fuller School is definitely data rich (huge
> stash @ Stanford).

Well, in the internet age, perhaps it might have been better to burn it 
all then give it to a place like Stanford? :-) This is assuming the heirs 
weren't prudent enough to insist Stanford make the information available 
for free-as-in-freedom use; perhaps they were? If the heirs had just 
burned it, and disclaimed copyright interests, then at least what little 
remained might feel free-er to use when derived from any second-hand 
source (there would still be issues though, from those sources). Does any 
small player really want to tangle with the Stanford IP licensing system 
when it smells money? I already saw Stanford's IP department (in my 
opinion) damage the Bootstrap Institute effort just as it got started, 
with a license designed by Stanford for Stanford's own short term benefit.
  http://www.bootstrap.org/dkr/discussion/1087.html
Anyway, I'm sure the Stanford Fuller Archive would be a wonderful place to 
make a visit to, and spend much time in for inspiration, but I think it 
unfortunately may have limited relevance to free internet activities 
otherwise, barring a lot of work by others (hint :-) to get Stanford to 
allow Fuller's works to be freely used online to make derived works.

I guess somehow I just assumed there would be freely licensed works 
related to Bucky. Too bad Bucky didn't do his work in the open source / 
free software age. Effectively, even if his work is readable for 
free-as-in-beer on the web, it is on practical basis then lost as far as 
being the basis for direct improvements for free-as-in-freedom new works. 
Still inspiring of course, for indirect use, but it sounds like, barring a 
lot of permissions work, the actual concrete realizations just need to be 
ignored when doing something new. :-( Which is a surprise.

To be clear, of course there is a lot of Bucky stuff on-line now, to be 
read exactly as it was written, and I am grateful to people such as 
yourself for making that happen. I'm sure even that was, and is, a lot of 
work. What I am talking about is more using it as a springboard to move 
further by cutting and pasting bits and pieces and reorganizing it into 
new derived works (like an educational Card stack). This isn't Bucky 
specific though; this a general problem for making any sort of new 
educational materials derived from any author's work. It just more ironic 
and frustrating to see works about building a newer and more prosperous 
society for everyone tied down by some of the same chains (mostly chains 
of assumptions :-) trying to keep the rest of society down.

Anyway, you made a great suggestion of using the ideas to generate images, 
and I think that is probably the best way for me to go if I made a 
HyperCard-like Bucky stack as a demo. And that's much the same reason I'm 
reinventing Squeak in Python rather than using it as it, with it's 
licensing issues and licensing heritage. Thanks again for the suggestion, 
it especially makes sense in a programming context. Each card could be a 
little mini-simulation with a topic and some code that draws a graphics 
with a 2D or 3D turtle.

Which of course leads me (lazy programmer that I am :-) to the thought, is 
there any free-as-in-freedom Python source code to draw Bucky structures 
on the net? :-)

--Paul Fernhout

From aharrin at luc.edu  Tue May 23 19:58:13 2006
From: aharrin at luc.edu (Andrew Harrington)
Date: Tue, 23 May 2006 12:58:13 -0500
Subject: [Edu-sig] testing interactive loops
In-Reply-To: <7528bcdd0605161414t191a0a65i745dd0d4be2c74da@mail.gmail.com>
References: <446A36A7.5000102@luc.edu>
	<7528bcdd0605161414t191a0a65i745dd0d4be2c74da@mail.gmail.com>
Message-ID: <44734D35.2030603@luc.edu>

For testing keyboard input loops in a tutorial, the issue with 
__builtin__ should not arise with Crunchy Frog code snippet testing, 
because the snippet is copied into a main module!  I like the idea of 
some marker for the main engine that a doctest is interactive.  Instead 
of the current doctest marker

we might use

or to indicate delimiters and their replacements we might use


and have the engine then change :: and ?? to : and ? and extract the 
input that follows them, and do the input redirection so doctest then works.

Andy

Andre Roberge wrote:

> On 5/16/06, *Andrew Harrington*  > wrote:
>
>     We have been discussing testing in tutorials with doctest.
>     There is one place that does not work, I think:  testing an
>     interactive
>     loop, which is a construction I teach in introductory programming.
>
>     It appears that doctest cannot handle interactive input.  I would
>     still
>     like to be able to illustrate a session with interactive input and
>     explicit output at the end, and check it automatically.
>
>     If you just do input redirection and compare the actual output to the
>     desired input, you get messed up because the input is not echoed when
>     you redirect from a file.
>
>     The following does not work, but is the idea you want, to force
>     the echo
>     when stdin become a file:
>
>     orig_raw_input = raw_input
>
>     def raw_input_echo(prompt=""):
>         s = orig_raw_input(prompt)
>         print s
>         return s
>
>     raw_input = raw_input_echo
>
>     def input_echo(prompt=""):
>         return eval(raw_input(prompt))
>
>     This fails because it makes raw_input a global for the current
>     module,
>     but not a built_in, so it fails when you import and use a module using
>     raw_input.
>
>
> How about:  (something totally untested)
> import ah  # module named after you :-)
> ah.raw_input = raw_input_echo
>
> And then you run your tests?...
>
> Andr?
>
>     I guess we could make it work in little code fragment tests, where
>     you
>     append the user's fragment to the code above, in the same module,
>     but it
>     is not a general solution.
>
>     Is there any better way to do this?
>
>     A kludge for tutorial doc tests would be to mark the prompt strings
>     somehow in the tutorial source, for instance making it always end with
>     :: or ?? so the test string can be parsed to find the responses that
>     come after the prompts, and put them in the input file and not in the
>     output file.  For example, the test string
>     ... Sum numbers!
>     ... Enter a number (or 0 to quit):: 3
>     ... Enter a number (or 0 to quit):: 4
>     ... Enter a number (or 0 to quit):: 8
>     ... Enter a number (or 0 to quit):: 0
>     ... The sum is 15!
>
>     might be processed for web display in the tutorial undoubling the ::
>
>     ... Sum numbers!
>     ... Enter a number (or 0 to quit): 3
>     ... Enter a number (or 0 to quit): 4
>     ... Enter a number (or 0 to quit): 8
>     ... Enter a number (or 0 to quit): 0
>     ... The sum is 15!
>
>     and the tutorial parser would also generate an input file
>     3
>     4
>     8
>     0
>
>     and output file
>
>     Sum numbers!
>     Enter a number (or 0 to quit):
>     Enter a number (or 0 to quit):
>     Enter a number (or 0 to quit):
>     Enter a number (or 0 to quit):
>     The sum is 15!
>
>     Then run the code with redirection and compare the desired and actual
>     output.  There still is the issue of the program hanging with the
>     given
>     input ...
>
>     How does regular doctest deal with infinite loops or waiting for
>     nonexistent keyboard input?
>
>
> ??
>  
>
>     Better ideas?
>
>     --
>       Andrew N. Harrington
>       Computer Science Department      Undergraduate Program Director
>       Loyola University Chicago        http://www.cs.luc.edu/~anh
>     
>       512B Lewis Towers (office)       Office Phone: 312-915-7982
>       Snail mail to Lewis Towers 416   Dept. Fax:    312-915-7998
>       820 North Michigan Avenue        aharrin at luc.edu
>     
>       Chicago, Illinois 60611
>
>     _______________________________________________
>     Edu-sig mailing list
>     Edu-sig at python.org 
>     http://mail.python.org/mailman/listinfo/edu-sig
>
>


-- 
  Andrew N. Harrington
  Computer Science Department      Undergraduate Program Director
  Loyola University Chicago        http://www.cs.luc.edu/~anh
  512B Lewis Towers (office)       Office Phone: 312-915-7982
  Snail mail to Lewis Towers 416   Dept. Fax:    312-915-7998
  820 North Michigan Avenue        aharrin at luc.edu
  Chicago, Illinois 60611          


From winstonw at stratolab.com  Tue May 23 20:30:07 2006
From: winstonw at stratolab.com (Winston Wolff)
Date: Tue, 23 May 2006 14:30:07 -0400
Subject: [Edu-sig] MakeBot release open-source
Message-ID: 

I have released MakeBot's source code with the MIT open source  
license.  Vern Cedar has expressed interest in getting a Linux  
version running.  You can now find the source at the project's Trac  
site:

	http://stratotools.python-hosting.com/

-Winston

______________________________________________________
winston wolff - (646) 827-2242 - http://www.stratolab.com
learning by creating - video game courses for kids in new york



From kirby.urner at gmail.com  Tue May 23 21:36:10 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Tue, 23 May 2006 12:36:10 -0700
Subject: [Edu-sig] Refocusing on Capabilities (was PySqueak)
In-Reply-To: <44731802.5080809@kurtz-fernhout.com>
References: 
	<447293E8.7030601@kurtz-fernhout.com>
	
	<44731802.5080809@kurtz-fernhout.com>
Message-ID: 

Hi Paul --

I think just apply the basic courtesies of scholarship and make it
easy for readers to trace to your sources (provided your sources wish
to be known -- I respect the journalist's right to interpose cover,
though some over use this as a license to be their own anonymous
source (it's often easy to tell as poor writing is poor writing).

Your edit/recombine job may be interesting, but many browsers just
want to get back to the same stashes you savor.  Adequate signage.
Unless you're actively keeping secrets, which you may do too, though
if at the expense of an unacknowledged starving artist in Hoboken or
such like, you're playing with karmic fire.

I have many rants against the priority-focused intellectual property
discourse of the west.  The whole of western civilization rests on
sources further east, and now comes around the globe through North
America trying to lecture Chinese on what's the matter with copying --
threatening the Chinese with proprietary gunpowders, how ironic.

Actually, I'm thinking the USA is already turning away from its broken
patent system and embracing the logic of open source, despite all the
demonization of same in the economist press.  For example Portland, my
home town, is safe haven to a new breed of entrepreneurial open source
capitalists for example.  We have many working business models and
plans to expand.

Working with Chinese on open source projects is far more productive
than trying to accelerate them through a course in US business law,
which is super-confusing even to its local practitioners.  Nobody has
time for all the fine print.  It'll just drive ya crazy.  So obviously
the computer world (which operates quickly) has already found plenty
of workarounds.

About your prototyping experiments:  I'm interested in learning more
about Self and would gladly attend lectures on same, at OSCON or
wherever.  Then I could better follow your logic.  My layman's
question, after reading your posts, is:  why not just keep Python
pythonic and Self selfish?

In other words, Python already has a very strong paradigm, very simple
to learn.  Why mess with that?  I guess I'm a purist in that regard.
But that doesn't make me a language bigot, as I fully respect the
right of other languages to define themselves around equally strong,
yet different, paradigms.  I'm also biased towards OO.

That doesn't mean I think the lambda calculus people can't hack their
own brands.  They already do, and quite successfully by the look of
things.

Kirby

From catherine.curley at gmail.com  Tue May 23 22:27:12 2006
From: catherine.curley at gmail.com (catherine curley)
Date: Tue, 23 May 2006 21:27:12 +0100
Subject: [Edu-sig] [Ann] DocTest solution: Crunchy Frog
In-Reply-To: <7528bcdd0605041931n2a43e564s442ac394a9b2e5a9@mail.gmail.com>
References: <7528bcdd0605032057v2c59df43s886457ba3a483163@mail.gmail.com>
	<7528bcdd0605041931n2a43e564s442ac394a9b2e5a9@mail.gmail.com>
Message-ID: 

Hi

Do I have to intall CherryPy and how.

>From  where do I run the setup program when running in Windows XP.

Thanks in advance

Catherine


On 5/5/06, Andre Roberge  wrote:
>
> Version 0.2 of Crunchy Frog is ready to be released.
>
> After refactoring the code in a major way, I have been able to
> implement *almost* all the non-graphical features I was hoping for.
>
> The code should now be very easy to understand, if you have some
> familiarity with CherryPy and ElementTree.
>
> Unfortunately, sourceforge appears to have been down for a while, so I
> haven't been able to upload it.  If you want to try it, and can`t find
> it on sourceforge, feel free to contact me by email and I'll send you
> a copy.  The updated 5 html files and 3 Python files fit in less than
> 10 kB (zip file).
>
> When you enter some Python code in an "editor area" and have Python
> execute the code, the code no longer disappear from the "editor area".
> This is the most important improvement, from a usability point of
> view.
>
> You can now also have an arbitrary combination of 'fake interpreter
> prompt', 'editor area' and 'DocTest areas' on a single page.
>
> The code that takes care of the execution of the user code has been
> extracted and put in a small module on its own.  Therefore, whenever
> one develops a "Python sandbox", it will be extremely simple to make
> use of it.
>
> There are three main features left to implement:
>
> 1. add the possibility to load "non-local" html files.  This might be
> as easy as adding a couple of lines of code, using a module like
> urllib.  When I figure out how to do that, I'll be pestering authors
> of existing Python tutorials to adapt them for use with Crunchy Frog
> ;-)
>
> 2. Fix a major annoyance for "long" pages: at present, when executing
> a code snippet, the page gets reloaded at the very top, even if the
> "editor area" or "fake interpreter prompt" was at the bottom of the
> page.  I haven`t been able to find out how to do this using CherryPy.
>
> 3. Being able to navigate in an arbitrary directory structure.  Up
> until now, I have had problems if the html files were not all in a
> single directory.
>
> There are a few other features (like saving a session) that I would
> like to ideally fix before version 1.0.
>
> The usage I make of CherryPy appears to be extremely minimal.  I
> suspect that someone familiar with web programming using the standard
> library would be able to reproduce what I did without too much
> programming efforts.  If anyone has any pointers as to how I could do
> this, I would appreciate it.
>
> As usual, any feedback including strong criticisms are welcome!
>
> Andr?
>
> On 5/4/06, Andre Roberge  wrote:
> > Version 0.1 of Crunchy Frog has been released.  It can be found at
> > https://sourceforge.net/project/showfiles.php?group_id=125834
> >
> > Crunchy Frog allows to transform a "traditional" Python tutorial into
> > an interactive session within your favourite web browser.  Three
> > "modes" of interaction are currently possible:
> > 1. one-liner, similar to the typical instruction at the Python
> interpreter.
> > 2. multi-line Python code, as entered in a traditional editor, and
> > executed by Python.
> > 3. Solutions to doctests, as described by Jeff Elkner in a previous
> post.
> >
> > Crunchy Frog is more of a proof-of-concept than a serious application
> > at this point. The code is rather messy, showing my total lack of
> > experience with this type of program (web app).  To use it you will
> > also need to have installed Elementtree (included with Python 2.5?)
> > and CherryPy.   You do not need to install Crunchy Frog.
> >
> > To try it: read the 5 (short) pages long "tutorial" included, using
> > your favourite browser.  Then, start Crunchy Frog, and go through the
> > tutorial again.  The whole thing should be doable in less than 10
> > minutes.
> >
> > Andr?
> >
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20060523/24a1bcc8/attachment.htm 

From andre.roberge at gmail.com  Wed May 24 03:32:52 2006
From: andre.roberge at gmail.com (Andre Roberge)
Date: Tue, 23 May 2006 22:32:52 -0300
Subject: [Edu-sig] RUR-PLE 0.9.8.2 release
Message-ID: <7528bcdd0605231832s4dcb6f4ax15792302f130871b@mail.gmail.com>

A new version of RUR-PLE has been released.  Actually, there's been quite a
few releases since the last announcement on this list.  Changes that have
been made since the last announcement (from memory) are:
1. auto-indentation of code
2. possibility of importing user-defined images for the robot
3. improved code-highlighting and stepping through
4. spaces are visible (helps beginner with indentation, and avoiding partly
blank lines which cause "invisible" syntax errors).
5. print statements in robot programs are now possible, with output
appearing in special "window"
6. input_int() and input_string() instructions in robot programs allow to
pass values to robot; this is not documented anywhere (yet) in the lessons.

Enjoy!  (and feel free to criticise)

Andr?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20060523/593b9d4d/attachment.htm 

From johannes.wollard at gmail.com  Wed May 24 16:02:56 2006
From: johannes.wollard at gmail.com (Johannes Woolard)
Date: Wed, 24 May 2006 15:02:56 +0100
Subject: [Edu-sig] [edu-sig] Hi from Summer of Code
Message-ID: <10c99c2a0605240702l46c144f5k7f45fea738aed473@mail.gmail.com>

Hi!
I think I've posted on here before, but I though I would introduce
myself properly:

I'm Johannes Woolard, from the UK, and I've just been accepted into
the google summer of code project to work on interactive python
tutorials. My mentor (I believe) is Andre Roberge, and my work will be
based on crunchy frog. For those of you interested, my proposal is
currently in two parts: the main body at
http://users.ox.ac.uk/~orie1763/coder-python.pdf and a revised
schedule at http://users.ox.ac.uk/~orie1763/coder3.txt (The schedule
actually describes everything I want to do). I've also set up a blog
at http://pytute.blogspot.com to write about my progress.

I look forward to working with everyone here, yrs,

Johannes Woolard

-- 
Johannes Woolard,
Oriel College, Oxford
OX1 4EW
07837880296
ox extn: 26611

From andre.roberge at gmail.com  Wed May 24 16:32:41 2006
From: andre.roberge at gmail.com (Andre Roberge)
Date: Wed, 24 May 2006 11:32:41 -0300
Subject: [Edu-sig] [edu-sig] Hi from Summer of Code
In-Reply-To: <10c99c2a0605240702l46c144f5k7f45fea738aed473@mail.gmail.com>
References: <10c99c2a0605240702l46c144f5k7f45fea738aed473@mail.gmail.com>
Message-ID: <7528bcdd0605240732s7d02e0c0o60f6484c6fd98e6@mail.gmail.com>

Hi everyone!

I know that some people here do not need encouragement to voice their
opinion but I would call upon all of you to try to at least *once* over the
next 13 weeks to take a look at what Johannes will have produced (which he
will announce here ... if not, *I* will) and give him some feedback.  The
more feedback he will receive, the better the result of the project will be.

The competition to get a project approved was rather fierce and "we" (on
edu-sig) should be grateful that at least one project relevant to "us" was
approved by the would-be Python mentors.   A successful outcome of this
project may influence the outcome of future Summer of Code competitions -
not to mention, the adoption of Python by more schools.

Personally, I am thrilled to be Johannes's mentor for this project.

Andr?

On 5/24/06, Johannes Woolard  wrote:
>
> Hi!
> I think I've posted on here before, but I though I would introduce
> myself properly:
>
> I'm Johannes Woolard, from the UK, and I've just been accepted into
> the google summer of code project to work on interactive python
> tutorials. My mentor (I believe) is Andre Roberge, and my work will be
> based on crunchy frog. For those of you interested, my proposal is
> currently in two parts: the main body at
> http://users.ox.ac.uk/~orie1763/coder-python.pdf and a revised
> schedule at http://users.ox.ac.uk/~orie1763/coder3.txt (The schedule
> actually describes everything I want to do). I've also set up a blog
> at http://pytute.blogspot.com to write about my progress.
>
> I look forward to working with everyone here, yrs,
>
> Johannes Woolard
>
> --
> Johannes Woolard,
> Oriel College, Oxford
> OX1 4EW
> 07837880296
> ox extn: 26611
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20060524/ae1aca3d/attachment.htm 

From aharrin at luc.edu  Wed May 24 19:51:12 2006
From: aharrin at luc.edu (Andrew Harrington)
Date: Wed, 24 May 2006 12:51:12 -0500
Subject: [Edu-sig] Crunchy Frog 0.3 released
In-Reply-To: <7528bcdd0605101857y7f6e8bb9k83633c158b845402@mail.gmail.com>
References: <7528bcdd0605101857y7f6e8bb9k83633c158b845402@mail.gmail.com>
Message-ID: <44749D10.5080506@luc.edu>

Dear Andre,

Wish list for Crunchy Frog:

1.  Fitting in with my previous brainstorming, the most important thing 
is allowing differential branching based on test or evaluate results.  
The most obvious is an alternate place to go when there is a test 
failure.  With the possibly helpful Python error messages, a learner may 
well be able to go back and fix an error directly, so the suggested 
place to get specific help on the error should be connect to a "Help on 
the error" button, which the learner can choose to press after giving up 
on further editing of the code and further evaluation of the code.

2.  A fancier version of reacting to testing would allow parsing of the 
error output and doing different things based on the error, for instance 
how many tests were passed before the first failure, or even based on 
the particular response to the test that triggered the error.

basically encode logic like
if no error:
  return topic23.html
if first error on test 1:
  return e1.html
elif first error on test 2:
  if output == '5':
     return t2_5.html
  elif output == '17':
    return t2_17.html
  else:
   return 2_other.html
elif first error on test 3:
  if ValueError:
    return ve3.html
  else:
    return 3_other.html
else:
   return other.html

To allow arbitrary choice, one approach would be to actually allow 
Python code to be specified.  I do not really like that idea:  I would 
prefer not to have to worry about submitted lessons being able to 
execute Trojan code.  Another alternative would be a list, in the order 
of the tests, with a URL for each location the first error could occur.  
In place of a URL there might be a list of  pairs of output string and 
URL.   I would have the final option be taken if none apply.  The above 
logic would translate into something like the following where ... mean 
skip to the last line, and * is a wildcard

topic23.html, e1.html, ["5":t2_5.html, "17":t2_17.html, *:2_other.html], 
[..."ValueError"*:ve3.html, *:3_other.html], other.html

3.  I just checked, you illustrate several "evaluate" windows per page.  
However only one full interpreter seems to work per page or maybe per 
session.
When I want cumulative results, with interspersed lesson details, it 
would be nice to give a response to the last typing, and then expect the 
user to type more into the same environment.  For this we would want to 
copy the history from the last page, insert a new comment above the text 
box to the same interpreter, and then whatever buttons or other new 
stuff is due.  Most flexibly, allow a next page to include a reference 
to insert the body of the last page at the top of the current one, 
followed by current page, with a text box for the interpreter continuing 
with the state for the same interpreter as before.  Ideally allow logic 
something like 2 above to choose what to do next based on what the user 
types or the response.

You should also be able to get a newly initialized  interpreter if you 
do not want to continue using the old one.

4.  I got Crunchy Frog hanging on my Windows XP machine when I clicked 
to start the tutorial.  This was after I had run the tutorial multiple 
times with no problem and terminated normally.  Sorry I do not remember 
what happened to give you a better idea at this point.  I'll try to note 
the error environment more completely if it happens again. 

5.  It looks like you can see previous pages with the Firefox back 
arrow, but things get messed up if you try to interact with an old 
page.  It would be lovely if the program would deal gracefully with that 
-- at least keeping a page ID and noting if an old page is submitted, 
and ignoring it and ?? jumping back to the last page in the sequence ??  
I am not sure how to respond and not lose the sequence completely.

I have further interests in adding and handling meta data.  I will post 
those ideas separately.

Andy

Andre Roberge wrote:

>Version 0.3 of "Crunchy Frog" has been released. It can be found at
>https://sourceforge.net/project/showfiles.php?group_id=125834
>
>Crunchy Frog transforms a "traditional" Python tutorial into an
>interactive session within your favourite web browser. Four modes of
>interaction are currently possible:
>1. One-liner, similar to the typical instruction at the Python interpreter.
>*NEW*  2. Embedded Python shell, within an html page.  This is a bit
>similar to Ian Bicking's HTConsole.
>3. Multi-line Python code, as entered in a traditional editor, and
>executed by Python.
>4. Solutions to doctests, as described by Jeff Elkner in a post on edu-sig.
>
>Even though it is an early release, Crunchy Frog could probably
>already be useful in a classroom situation. To use it, you will also
>need to have installed Elementtree and CherryPy.
>
>Suggestion: read the 6 page long "tutorial" included, using your
>favourite browser. Then, start Crunchy Frog, and go through the
>tutorial again. The whole thing should be doable in approximately 15
>minutes (20 for Kirby, according to a previous message ;-) ... if you
>don't spend too much time playing with the new interpreter. :-)
>
>Andr?
>_______________________________________________
>Edu-sig mailing list
>Edu-sig at python.org
>http://mail.python.org/mailman/listinfo/edu-sig
>  
>
-- 
  Andrew N. Harrington
  Computer Science Department      Undergraduate Program Director
  Loyola University Chicago        http://www.cs.luc.edu/~anh
  512B Lewis Towers (office)       Office Phone: 312-915-7982
  Snail mail to Lewis Towers 416   Dept. Fax:    312-915-7998
  820 North Michigan Avenue        aharrin at luc.edu
  Chicago, Illinois 60611          


From andre.roberge at gmail.com  Wed May 24 20:53:11 2006
From: andre.roberge at gmail.com (Andre Roberge)
Date: Wed, 24 May 2006 15:53:11 -0300
Subject: [Edu-sig] Crunchy Frog 0.3 released
In-Reply-To: <44749D10.5080506@luc.edu>
References: <7528bcdd0605101857y7f6e8bb9k83633c158b845402@mail.gmail.com>
	<44749D10.5080506@luc.edu>
Message-ID: <7528bcdd0605241153x7457e94bqfd9477496a603db1@mail.gmail.com>

Dear Andrew,

Thanks for your message.  There is lots of food for thought in there.
I'll have to think some more about these issues, and I'm sure that Johannes
Woolard will too. :-)

I'll just give you (and other readers) a few quick first-impression
comments.

On 5/24/06, Andrew Harrington  wrote:
>
> Dear Andre,
>
> Wish list for Crunchy Frog:
>
> 1.  Fitting in with my previous brainstorming, the most important thing
> is allowing differential branching based on test or evaluate results.
> The most obvious is an alternate place to go when there is a test
> failure.  With the possibly helpful Python error messages, a learner may
> well be able to go back and fix an error directly, so the suggested
> place to get specific help on the error should be connect to a "Help on
> the error" button, which the learner can choose to press after giving up
> on further editing of the code and further evaluation of the code.


Branching depending on test results:
a) In terms of programming flexibility, it should be possible to implement a
way to do this.
b) In terms of curriculum design ... this is a lot more difficult to do.
There are two possibilities I see:
i) Identify the type of conceptual error that lead to a wrong answer.  One
needs to be prescient and figure out all possible wrong possibilities....
ii) Have a series of exercises by topic and, given a high failure rate in a
given topic, redirect to simpler, more basic exercises on prerequisite
topics to be understood.

Again, I think it is more a curriculum design ('content') than a programming
issue ('framework').  Crunchy Frog is intended to be a flexible framework.

Perhaps I am missing something deep here...

2.  A fancier version of reacting to testing would allow parsing of the
> error output and doing different things based on the error, for instance
> how many tests were passed before the first failure, or even based on
> the particular response to the test that triggered the error.
>
> basically encode logic like
> if no error:
>   return topic23.html
> if first error on test 1:
>   return e1.html
> elif first error on test 2:
>   if output == '5':
>      return t2_5.html
>   elif output == '17':
>     return t2_17.html
>   else:
>    return 2_other.html
> elif first error on test 3:
>   if ValueError:
>     return ve3.html
>   else:
>     return 3_other.html
> else:
>    return other.html


Again, I see the framework to be design in a way that this could be
accommodated... but the real challenge is coming up with the detailed course
content.


[snip]
>
> 3.  I just checked, you illustrate several "evaluate" windows per page.


Yes.

However only one full interpreter seems to work per page or maybe per
> session.


True... at the moment.  This is something I want to take care of.

When I want cumulative results, with interspersed lesson details, it
> would be nice to give a response to the last typing, and then expect the
> user to type more into the same environment.


Yes, I am planning to have this flexibility built-in.


For this we would want to
> copy the history from the last page, insert a new comment above the text
> box to the same interpreter, and then whatever buttons or other new
> stuff is due.  Most flexibly, allow a next page to include a reference
> to insert the body of the last page at the top of the current one,
> followed by current page, with a text box for the interpreter continuing
> with the state for the same interpreter as before.


Actually, I see the interpreter as an environment for "quick and dirty"
tests.  I see the editor (which will need to be improved) as the place to do
some more serious tests - with the possibility of "remembering" the input
from editor on page N, after successful result (say of running a doctest)
and putting it as an initial value in the editor on page N+1.

Ideally allow logic
> something like 2 above to choose what to do next based on what the user
> types or the response.
>
> You should also be able to get a newly initialized  interpreter if you
> do not want to continue using the old one.


Yes, there should be a way to restart the interpreter.  (Right now, you
simply need to reload the page :-)


4.  I got Crunchy Frog hanging on my Windows XP machine when I clicked
> to start the tutorial.  This was after I had run the tutorial multiple
> times with no problem and terminated normally.  Sorry I do not remember
> what happened to give you a better idea at this point.  I'll try to note
> the error environment more completely if it happens again.


ok

5.  It looks like you can see previous pages with the Firefox back
> arrow, but things get messed up if you try to interact with an old
> page.  It would be lovely if the program would deal gracefully with that
> -- at least keeping a page ID and noting if an old page is submitted,
> and ignoring it and ?? jumping back to the last page in the sequence ??
> I am not sure how to respond and not lose the sequence completely.


I've started to look at that.  Right now, it does not work for the
interpreter .... and I am not sure it's worth trying to implement.


I have further interests in adding and handling meta data.  I will post
> those ideas separately.
>
> Andy
>
> Andre Roberge wrote:
>
> >Version 0.3 of "Crunchy Frog" has been released. It can be found at
> >https://sourceforge.net/project/showfiles.php?group_id=125834
> >
> >Crunchy Frog transforms a "traditional" Python tutorial into an
> >interactive session within your favourite web browser. Four modes of
> >interaction are currently possible:
> >1. One-liner, similar to the typical instruction at the Python
> interpreter.
> >*NEW*  2. Embedded Python shell, within an html page.  This is a bit
> >similar to Ian Bicking's HTConsole.
> >3. Multi-line Python code, as entered in a traditional editor, and
> >executed by Python.
> >4. Solutions to doctests, as described by Jeff Elkner in a post on
> edu-sig.
> >
> >Even though it is an early release, Crunchy Frog could probably
> >already be useful in a classroom situation. To use it, you will also
> >need to have installed Elementtree and CherryPy.
> >
> >Suggestion: read the 6 page long "tutorial" included, using your
> >favourite browser. Then, start Crunchy Frog, and go through the
> >tutorial again. The whole thing should be doable in approximately 15
> >minutes (20 for Kirby, according to a previous message ;-) ... if you
> >don't spend too much time playing with the new interpreter. :-)
> >
> >Andr?
> >_______________________________________________
> >Edu-sig mailing list
> >Edu-sig at python.org
> >http://mail.python.org/mailman/listinfo/edu-sig
> >
> >
> --
>   Andrew N. Harrington
>   Computer Science Department      Undergraduate Program Director
>   Loyola University Chicago        http://www.cs.luc.edu/~anh
>   512B Lewis Towers (office)       Office Phone: 312-915-7982
>   Snail mail to Lewis Towers 416   Dept. Fax:    312-915-7998
>   820 North Michigan Avenue        aharrin at luc.edu
>   Chicago, Illinois 60611
>
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20060524/750546c1/attachment-0001.htm 

From aharrin at luc.edu  Wed May 24 23:16:11 2006
From: aharrin at luc.edu (Andrew Harrington)
Date: Wed, 24 May 2006 16:16:11 -0500
Subject: [Edu-sig] An engine to navigate between lessons
In-Reply-To: <7528bcdd0605142056u1809b793vbac83bf33029f992@mail.gmail.com>
References: <28855600.1147613361435.JavaMail.root@blb34.blogger.com>	
	<7528bcdd0605140955o47cb768fw20f24663d2052ccb@mail.gmail.com>	
		
	<7528bcdd0605141418m248037dex61a708677d4eba30@mail.gmail.com>	
		
	<7528bcdd0605141815q2665207ds1df26e1a248bc3de@mail.gmail.com>	
	<4467E711.8080704@luc.edu>
	<7528bcdd0605142056u1809b793vbac83bf33029f992@mail.gmail.com>
Message-ID: <4474CD1B.2060701@luc.edu>

Andre Roberge wrote:
 > On 5/14/06, Andrew Harrington  wrote:
 >> Navigating Between Lessons

 >> I have been reading the discussion and trying the prototypes for Python
 >> content delivery with great excitement.  On seeing how well you were
 >> doing on the content delivery, my imagination took off and I wrote down
 >> a whole bunch of brainstorming ideas below on an important independent
 >> aspect of an interactive learning environment.  Just tonight the "Only
 >> Python" thread touched on the area I have been thinking about with the
 >> idea of choosing what comes next after evaluating code in the 
Crunchy Frog.

 > [snip - snip - snip     lots of interesting material cut out.]

 > There were a lot of great ideas expressed in this brainstorming 
tsunami. 

Thanks!

 > I will latch onto a single theme.

 > For this to work, we need tutorials "snippets" ... lots of them. 

For sure.  Snippets is a good term, too.

 > I don't
 > think we need to worry too much at this point about complex links
 > between them, nor about the "syntax" required for those links.  I
 > believe this is going to be the easy part ... after enough tutorial 
snippets
 > are written.  If it is web-based, the whole machinery pretty much
 > already exists. One way might be to embed keywords, including
 > "difficulty ranking", inside tutorials and use a search engine to decide
 > where to go next.  Or, rather than using a search engine, a "mind map"
 > type of visual index can be created, with some automatic updating
 > whenever a new tutorial snippet is added, or a keyword is added to that
 > tutorial.  A variation on the them is that keywords inside a given
 > tutorial could be given some relative weighting factor.

All of those methods could be used inside a particular lesson generator 
like Crunchy Frog.  I was certainly thinking of embedding stuff in the 
html for Crunchy Frog.  Having everything there is part of the elegant 
simplicity of generating data for Crunch Frog.

 > Regardless of the chosen method ... lots of tutorials will be needed. 
 > Until then, I think that trying to come up with the ideal method to link
 > them is probably pointless; a case of premature optimization....

 > Andr?

Certainly much of the elaboration of an engine is mostly useful after 
there are lots of lessons, and certainly the stuff about using learning 
histories to tweak the engine is WAY in the future.

A major point I did not consider, that fits into your caution about 
premature optimization, is that Crunchy Frog is the only delivery 
mechanism at the moment, so all data comes through it, and we can 
concentrate on Crunchy Frog understanding data embedded in a Crunchy 
Frog Web page lesson.

I see data embedded in meta data, your custom vlam attributes, and 
classes identifying types of content:

The meta construction in the heading is a fine basic descriptive format 
for use by Crunchy Frog.  It is important that the format is clear:  
agreeing on what name attributes are used and the meaning of the content 
attribute that goes with a name. 

We could make skills binary as in




or as I prefer, with a numeric rating, maybe with the number left out 
meaning 100 (mastery) and 0 meaning exposure.  The following might be in 
a testing module on understanding the flow of control in an if-else 
construction, assuming an earlier expository introduction:




There is much meta data about a lesson that I think is useful, even when 
our total number of lessons is small.  A lot of the data is most 
obviously considered while creating a lesson, when I find it easiest to 
add classifications, and to edit them from a copy of a similar template 
lesson.

If we are piecing together snippets of tutorial, I think it is important 
to be conscious of what the prerequisites are and what is being taught.  
I would be happy to give a first pass on a consistent pattern for naming 
basic and composite skills for introductory programming in Python.    I 
still like the idea of short names for composite skills, so a persistent 
structure is needed to store components of compound skills.  One simple 
approach would be to use a text file with Python dictionary syntax and 
list value
"loops":["forLoop", "whileLoop"]
"booleanExpression":["booleanExpressionAtomic", "andOp", "orOp", "notOp"]

Other conventions, use keywords, author, and version.  For example:





I need more research on what is relevant and practical, but I imagine 
various measures of the speed and creative ability needed of the 
learner, maybe difficulty (pretty general) or more specifically speed, 
repetitiveness, number of new ideas together, number of solution steps 
the learner must put together independently, ....  Even if names are 
agreed upon here, the initial measures are subjective, and probably only 
make sense being added when comparing a number of lessons.   This is an 
area where I look to have an eventual system make tweaks dynamically 
based on statistics from learner histories.

I imagine one lesson having multiple screens, and maybe multiple paths 
if help is given for wrong answers.  I treat the final page of a lesson 
covering a defined topic as being different from the others.  I imagine 
a "Next page" or other buttons in intermediate pages, as I mentioned in 
my recent Crunchy Frog wish list, and a "Next lesson" button at the 
end.  Data associated with the Next Lesson button might include several 
lessons of the authors that could logically follow independently. Maybe 
the first one would be chosen if there is no further basis for choosing 
added.  I would like to get to a point where the objectives of the 
learner are part of the state, and that affects the choice of the next 
lesson. 

I have looked through many narrative tutorial introductions, and I still 
like the idea of being able to extract a reference on what has been 
introduced so far.  I like the idea of marking new syntax and summaries 
in the expository text, maybe with a

, and 
, making them easy to 
extract with Elementtree, and consistent in their display.   It would be 
nice for these summaries to pop up in a separate window or tab if 
requested.  I do not know if that fits in with the Python localhost 
interface.  If there had been any of these elements in lessons so far, I 
would put Syntax and Summary buttons somewhere, at the bottom of the 
lesson page or on a separate reference web page, or in a separate frame.

There is an embedded style in Crunchy from pages.  Styles for syntax and 
summary could be added.

Again, some agreement on a starting scheme is useful.  Other people's 
suggestions/agreements much appreciated.

-- 
  Andrew N. Harrington
  Computer Science Department      Undergraduate Program Director
  Loyola University Chicago        http://www.cs.luc.edu/~anh
  512B Lewis Towers (office)       Office Phone: 312-915-7982
  Snail mail to Lewis Towers 416   Dept. Fax:    312-915-7998
  820 North Michigan Avenue        aharrin at luc.edu
  Chicago, Illinois 60611          


From andre.roberge at gmail.com  Thu May 25 00:41:59 2006
From: andre.roberge at gmail.com (Andre Roberge)
Date: Wed, 24 May 2006 19:41:59 -0300
Subject: [Edu-sig] An engine to navigate between lessons
In-Reply-To: <4474CD1B.2060701@luc.edu>
References: <28855600.1147613361435.JavaMail.root@blb34.blogger.com>
	<7528bcdd0605140955o47cb768fw20f24663d2052ccb@mail.gmail.com>
	
	<7528bcdd0605141418m248037dex61a708677d4eba30@mail.gmail.com>
	
	<7528bcdd0605141815q2665207ds1df26e1a248bc3de@mail.gmail.com>
	<4467E711.8080704@luc.edu>
	<7528bcdd0605142056u1809b793vbac83bf33029f992@mail.gmail.com>
	<4474CD1B.2060701@luc.edu>
Message-ID: <7528bcdd0605241541h6587da7ak4a553b4e148bcb9b@mail.gmail.com>

On 5/24/06, Andrew Harrington  wrote:[snip]
As usual, Andrew has expressed much too many different (and excellent!)
ideas for me to be able to address them all.  I'll focus on a few of them.

...
> I see data embedded in meta data, your custom vlam attributes, and
> classes identifying types of content:
>
> The meta construction in the heading is a fine basic descriptive format
> for use by Crunchy Frog.  It is important that the format is clear:
> agreeing on what name attributes are used and the meaning of the content
> attribute that goes with a name.
>
> We could make skills binary as in
>
> 
> 
>
> or as I prefer, with a numeric rating, maybe with the number left out
> meaning 100 (mastery) and 0 meaning exposure.  The following might be in
> a testing module on understanding the flow of control in an if-else
> construction, assuming an earlier expository introduction:
>
> 
> 
>
> There is much meta data about a lesson that I think is useful, even when
> our total number of lessons is small.  A lot of the data is most
> obviously considered while creating a lesson, when I find it easiest to
> add classifications, and to edit them from a copy of a similar template
> lesson.
>
> If we are piecing together snippets of tutorial, I think it is important
> to be conscious of what the prerequisites are and what is being taught.
> I would be happy to give a first pass on a consistent pattern for naming
> basic and composite skills for introductory programming in Python.    I
> still like the idea of short names for composite skills, so a persistent
> structure is needed to store components of compound skills.  One simple
> approach would be to use a text file with Python dictionary syntax and
> list value
> "loops":["forLoop", "whileLoop"]
> "booleanExpression":["booleanExpressionAtomic", "andOp", "orOp", "notOp"]


Using  is a great way to embed information.  It is not something
that would create any syntax problem when viewed in a normal html browser;
even better, it would be ok'ed by htmlTidy!

In terms of "content": rather than creating a new syntax (e.g. andOp, orOp),
why not simply use Python keywords, syntax, or built-in functions as is
whenever possible.  For example:




[snip]


I have looked through many narrative tutorial introductions, and I still
> like the idea of being able to extract a reference on what has been
> introduced so far.  I like the idea of marking new syntax and summaries
> in the expository text, maybe with a
> 
, and 
, making them easy to
> extract with Elementtree, and consistent in their display.   It would be
> nice for these summaries to pop up in a separate window or tab if
> requested.


Classes for content/display mode are a good idea.

I do not know if that fits in with the Python localhost
> interface.  If there had been any of these elements in lessons so far, I
> would put Syntax and Summary buttons somewhere, at the bottom of the
> lesson page or on a separate reference web page, or in a separate frame.


I don't like frames... but there are ways with dynamic html to hide and show
content. And, I agree that the interface should be consistent - at the very
least, within a single tutorial, spanning many pages.  Eventually (version
1.0), it would be nice to have a standardisation convenient yet complete
enough to be adopted by everyone.

There is an embedded style in Crunchy from pages.  Styles for syntax and
> summary could be added.


Agreed.

Again, some agreement on a starting scheme is useful.


I think this is going to evolve quasi-organically.

Other people's suggestions/agreements much appreciated.


Indeed!!!

Andr?


> --
>   Andrew N. Harrington
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20060524/6ad826c4/attachment.htm 

From aharrin at luc.edu  Fri May 26 16:24:40 2006
From: aharrin at luc.edu (Andrew Harrington)
Date: Fri, 26 May 2006 09:24:40 -0500
Subject: [Edu-sig] new python // and /
Message-ID: <44770FA8.9090803@luc.edu>

As I gear up to write or translate lessons for Crunchy Frog, I would 
like feedback on one general issue: 
//  -- the new integer division operator.

// is already legal in Python 2.4, though / still means the same thing 
for integers.  That is to change in Python 2.5, that is already in alpha 
2: 
/ as integer division will able to be set to mean the old operator or 
always mean real division (I forget which is the default in 2.5).

I think this is an excellent change in Python.  I would encourage using 
// for integer division in all newly written lessons.  There is the 
issue in 2.4 that you still have to go through an extra cast if you want 
real division,
x = 5
y = 3
real_quotient = float(x)/y

but there is nothing for that at the moment

-- 
  Andrew N. Harrington
  Computer Science Department      Undergraduate Program Director
  Loyola University Chicago        http://www.cs.luc.edu/~anh
  512B Lewis Towers (office)       Office Phone: 312-915-7982
  Snail mail to Lewis Towers 416   Dept. Fax:    312-915-7998
  820 North Michigan Avenue        aharrin at luc.edu
  Chicago, Illinois 60611          


From aharrin at luc.edu  Fri May 26 16:40:10 2006
From: aharrin at luc.edu (Andrew Harrington)
Date: Fri, 26 May 2006 09:40:10 -0500
Subject: [Edu-sig] new python // and /
In-Reply-To: <44770FA8.9090803@luc.edu>
References: <44770FA8.9090803@luc.edu>
Message-ID: <4477134A.7040803@luc.edu>

On // and /,
I neglected to mention that in Python 2.4 you can already use / for real 
division in any file where the top line imports from future:

from __future__ import division

Andrew Harrington wrote:

>As I gear up to write or translate lessons for Crunchy Frog, I would 
>like feedback on one general issue: 
>//  -- the new integer division operator.
>
>// is already legal in Python 2.4, though / still means the same thing 
>for integers.  That is to change in Python 2.5, that is already in alpha 
>2: 
>/ as integer division will able to be set to mean the old operator or 
>always mean real division (I forget which is the default in 2.5).
>
>I think this is an excellent change in Python.  I would encourage using 
>// for integer division in all newly written lessons.  There is the 
>issue in 2.4 that you still have to go through an extra cast if you want 
>real division,
>x = 5
>y = 3
>real_quotient = float(x)/y
>
>but there is nothing for that at the moment
>
>  
>


-- 
  Andrew N. Harrington
  Computer Science Department      Undergraduate Program Director
  Loyola University Chicago        http://www.cs.luc.edu/~anh
  512B Lewis Towers (office)       Office Phone: 312-915-7982
  Snail mail to Lewis Towers 416   Dept. Fax:    312-915-7998
  820 North Michigan Avenue        aharrin at luc.edu
  Chicago, Illinois 60611          


From guido at python.org  Fri May 26 19:02:15 2006
From: guido at python.org (Guido van Rossum)
Date: Fri, 26 May 2006 10:02:15 -0700
Subject: [Edu-sig] new python // and /
In-Reply-To: <44770FA8.9090803@luc.edu>
References: <44770FA8.9090803@luc.edu>
Message-ID: 

On 5/26/06, Andrew Harrington  wrote:
> As I gear up to write or translate lessons for Crunchy Frog, I would
> like feedback on one general issue:
> //  -- the new integer division operator.

It's hardly new; it was introduced in 2.2.

> // is already legal in Python 2.4, though / still means the same thing
> for integers.  That is to change in Python 2.5, that is already in alpha
> 2:
> / as integer division will able to be set to mean the old operator or
> always mean real division (I forget which is the default in 2.5).

Where did you get this? / won't change its meaning until 3.0. Ever
since 2.2 you can force it to mean real division by using "from
__future__ import division".

> I think this is an excellent change in Python.  I would encourage using
> // for integer division in all newly written lessons.

Right. We've been encouraging this ever since 2.2.

> There is the
> issue in 2.4 that you still have to go through an extra cast if you want
> real division,
> x = 5
> y = 3
> real_quotient = float(x)/y
>
> but there is nothing for that at the moment

Unless you want to promote the __future__ statement above. But that's
questionable for newbies -- it's better to teach the current language.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From pdfernhout at kurtz-fernhout.com  Fri May 26 20:13:06 2006
From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout)
Date: Fri, 26 May 2006 14:13:06 -0400
Subject: [Edu-sig] new python // and /
In-Reply-To: <44770FA8.9090803@luc.edu>
References: <44770FA8.9090803@luc.edu>
Message-ID: <44774532.3070304@kurtz-fernhout.com>

I would just like to point out that Python (compared to Smalltalk)
   http://www.smalltalk.org/articles/article_20041008_a1.html
has always done division wrong, and the new approach still does division 
wrong, IMHO, from a mathematical (not implementation) perspective. :-) In 
a dynamic object system, especially one oriented towards beginners at all, 
the proper result from division of two whole numbers is a "fraction". 
Fractions can be represented as a special type of mathematical object 
different from either an integer or a floating point number, with the 
order of promotion when mixing various types being integer -> fraction -> 
floating point. Multiplying two fractions should still yield a fraction 
(unless it reduces, e.g. 3/5 * 5/3 --> 15 / 15 --> 1). Smalltalk has done 
this for twenty plus years. It's the way mathematicians work on the 
chalkboard (if any still do. :-) when working with equations and reducing 
terms. It lends itself to generalizations, like including units into 
expressions and reducing or multiplying units. if the mathematics library 
is written to be extensible. It's the way grade school math is taught. It 
avoids a loss of precision (converting, say, 2/3 to the imprecise 
0.66666666666666663) until explicitly required (e.g. "float(2/3)"). If you 
want a float from a fraction, then in such a system you should generate it 
yourself, either by making one of the numbers a float (e.g. 3.0 / 5) or by 
taking the fractional result and converting it to a float ("float(3/5)"). 
Obviously "float(2/3)" in Python as it is now yields 0.0 not 
0.59999999999999998. Python as a community is still stuck in an integer 
vs. floating point mindset left over from C, IMHO.

Having said that, I don't necessarily think Guido is making the wrong 
decision for the overall Python community or language, e.g. his comments here:
   http://mail.python.org/pipermail/python-dev/2001-March/013587.html
Just one example of how when a language goes down one path from a set of 
choices, it kind of gets stuck with them, and builds a community 
comfortable with those decisions (where others uncomfortable with them use 
other systems); the same is generally true for mailing lists about any 
topic :-).

The bigger issue here is actually that in Smalltalk these sort of things 
are done by user accessible libraries, and so you could use a different 
math library or extend the current one without changing the language, 
whereas in Python (especially in the past) they are more under the covers 
hidden in C and built into the system, at least as far as is generally 
thought and discussed. Still, here is Python implementation of fractions 
done by Mike Hostetler:
   http://users.binary.net/thehaas/fractionpy.shtml
(haven't tried it myself though.) So, it is possible. And as Python moves 
to more generally unified types and objects by default, stuff like that 
may be done more and more as more people think of it. And I think it would 
be nice for a standard to evolve for that, especially from a "using Python 
to teach mathematics" standpoint.

Personally, I think that since one isn't going to be doing much serious 
number crunching computation in Python itself (compared to NumPy or some 
other library accessed through Python) that having fractions in Python 
isn't much of a performance issue in practice (more a coding style change 
if anything to be explicit about floats). But it certainly is a potential 
major compatibility issue, so I can see the argument for the current 
approach, although to be fair, any minor change affecting math is a major 
compatibility issue, and the current behavior of 2/3 == 0 is always 
surprising. It would seem problematical to beginners to need to learn yet 
another operator, yet another inconsistency, and so on, before it is 
needed; I have no problem by itself with a "//" operator, which is useful 
in special circumstances, as is one to yield a remainder, see for example:
   http://mail.python.org/pipermail/python-list/2001-August/060184.html
So I think from a pedagogical point of view, getting kids to use "//" when 
"/" really should be OK at the start and maps onto the infix syntax they 
already know is at the very best an ugly necessity to gain other Python 
benefits, given how Smalltalk shows that operator is not needed for 
routine mathematics or for beginners.

Still, given the current situation, I think your suggestion makes sense.

--Paul Fernhout

Andrew Harrington wrote:
> As I gear up to write or translate lessons for Crunchy Frog, I would 
> like feedback on one general issue: 
> //  -- the new integer division operator.
> 
> // is already legal in Python 2.4, though / still means the same thing 
> for integers.  That is to change in Python 2.5, that is already in alpha 
> 2: 
> / as integer division will able to be set to mean the old operator or 
> always mean real division (I forget which is the default in 2.5).
> 
> I think this is an excellent change in Python.  I would encourage using 
> // for integer division in all newly written lessons.  There is the 
> issue in 2.4 that you still have to go through an extra cast if you want 
> real division,
> x = 5
> y = 3
> real_quotient = float(x)/y
> 
> but there is nothing for that at the moment
> 

From kirby.urner at gmail.com  Fri May 26 20:12:30 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Fri, 26 May 2006 11:12:30 -0700
Subject: [Edu-sig] Accessibility to non CS types?
Message-ID: 

Given Python's original goal was to be friendly to techies who are not
specifically computer scientists, I'm finding it telling how few
physics majors get any exposure to the language, even today.

Even though it's used a lot on the job in many walks of life (per
success stories), I think we could do better.

I'm not blaming Python per se, but I think the OO paradigm shift left
many competent coders behind, still remembering a golden age when they
were able to get work done using Fortran or Pascal.

Now they open a tutorial or book on such as Python, and immediately
feel lost.  There's a lot of new jargon, and not many references to
languages they already know.  Where is "Python for Pascal
programmers"?

One might say this is only a generation gap and people new to coding
are picking up the latest and greatest concepts.  Unfortunately, I'm
seeing a lot of evidence that this is not true, at least not outside
of CS departments, because it's the older generation that's teaching
the younger, and now that they've lost proficiency, they're making do
with inappropriate and inadequate solutions a lot of the time.

In sum, I think Python could be reaching more people than it is,
including in its original target demographic (technical people needing
an easy computer language).

For more background, check out my latest blog post here:
http://worldgame.blogspot.com/2006/05/coffee-shop-physics.html

Kirby

From guido at python.org  Fri May 26 21:06:25 2006
From: guido at python.org (Guido van Rossum)
Date: Fri, 26 May 2006 12:06:25 -0700
Subject: [Edu-sig] Accessibility to non CS types?
In-Reply-To: 
References: 
Message-ID: 

On 5/26/06, kirby urner  wrote:
> Given Python's original goal was to be friendly to techies who are not
> specifically computer scientists,

Actually, that was ABC's goal. Python's original goal was to be a
scripting language for people already fluent in C and sh.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From pdfernhout at kurtz-fernhout.com  Fri May 26 21:53:21 2006
From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout)
Date: Fri, 26 May 2006 15:53:21 -0400
Subject: [Edu-sig] Refocusing on Capabilities (was PySqueak)
In-Reply-To: 
References: 	
	<447293E8.7030601@kurtz-fernhout.com>	
		
	<44731802.5080809@kurtz-fernhout.com>
	
Message-ID: <44775CB1.6030600@kurtz-fernhout.com>

kirby urner wrote:
> About your prototyping experiments:  I'm interested in learning more 
> about Self and would gladly attend lectures on same, at OSCON or 
> wherever.  Then I could better follow your logic.

Save yourself the airline fair :-) and just watch online:
   http://video.google.com/videoplay?docid=5776880551404953752
or:
   http://www.smalltalk.org.br/movies/
At least to see the basics.

For textual statement of the key issue, see:
   http://en.wikipedia.org/wiki/Self_programming_language
"The problem: Traditional object languages are based on a deep-rooted 
duality. Classes define the basic qualities and behaviours of objects, and 
instances are a particular object based on a class. ... Unless one can 
predict with certainty what qualities the objects will have in the distant 
future, one cannot design a class hierarchy properly. All too often the 
program will evolve to need added behaviours, and suddenly the whole 
system must be re-designed (or refactored) to break out the objects in a 
different way. Experience with early OO languages like Smalltalk showed 
that this sort of issue came up again and again. Systems would tend to 
grow to a point and then become very rigid, as the basic classes deep 
below the programmer's code grew to be simply "wrong". [My note: I think 
Squeak got to that point of rigidity long ago. :-) ] Without some way to 
easily change the original class, serious problems could arise. ... In 
general, such changes had to be done very carefully, as other objects 
based on the same class might be expecting this "wrong" behavior: "wrong" 
is often dependent on the context. ... The problem here is that there is a 
duality, classes and instances. Self simply eliminated this duality. ... 
This may not sound earth shattering, but in fact it greatly simplifies 
dynamism. If you have to fix a problem in some "base class" because your 
program has a problem, simply change it and make copies of that new object 
instead. No other program will see this change. ... This dramatically 
simplifies the entire OO concept as well. Everything might be an object in 
traditional system, but there is a very fundamental difference between 
classes and instances. In Self, there isn't."

Now this perhaps paints an overly rosy picture of the solution. In 
practice, how libraries are written and what tools you use make a big 
difference too. And Python's use of namespaces make possible management of 
some of these issues in a different way. Still, I think there remains of 
core of truth to this, at least as a sense of the overall "tone" of 
development. You really need to see it in action, like with the video, to 
really grasp what is possible and what is different about, at the very 
least, the GUI development paradigm (which in some ways is not that unlike 
Delphi or VB, but applicable to even regular objects).

> My layman's question, after reading your posts, is:  why not just keep
> Python pythonic and Self selfish?
> 
> In other words, Python already has a very strong paradigm, very simple 
> to learn.  Why mess with that?  I guess I'm a purist in that regard. 
> But that doesn't make me a language bigot, as I fully respect the right
> of other languages to define themselves around equally strong, yet
> different, paradigms.  I'm also biased towards OO.
> 
> That doesn't mean I think the lambda calculus people can't hack their 
> own brands.  They already do, and quite successfully by the look of 
> things.

This is a good question and a good related comment.

In general, you are right of course. And I understand your point about
language bigotry. I agree, and I think it is not bigotry to say a language
does certain things well, and if you want to do those things well and
easily, stick with its  mainstream approach. Languages have cultures and
paradigms, and you swim against them at your own cost (especially in terms
of productivity).

Still, I wonder if dominant paradigms in the future will be mainly OCaml
(or a derivative) as a better C, and something derived from Self (maybe
with Python syntax) as a better Smalltalk. I understood the value of OCaml
much better when I stopped thinking of it as a Python or Smalltalk
replacement but instead as a C/C++ replacement. I'm not even sure the
OCaml community sees themselves that way; they almost certainly don't. :-)

Python is stuck in the middle there, and sometimes that is a great place
to be (especially at the right time), and sometimes it isn't (especially
if times change, in part due to its own success). I feel Python as a
community right now as it contemplates its own evolution is torn between
types and prototypes. Like Squeak, it has developed its own approach
to solving the type problem by having a mini-language in the PyPy project,
but, while I think it is a neat thing to try, I am left wondering if
perhaps it might be better to just use something like Ocaml for that
purpose. As an analogy, I read there was a Basic English that all
aircraft pilots and control tower operators were supposed to learn
of a hundred or so English word to allow any pilot
to land at any airport. Worked well for all the non-native English
speakers, but the people who had problems with it were surprisingly
the native English speakers, because they has problems remembering
what they could say and what they could not. So, perhaps,
except for a single purpose of maintaining a VM, a language like
Squeak's slang or RPython will never have the value that
something like OCaml will have as a general tool. So, back to
my point of maybe types and prototypes being dominant paradigms, with
types implementing performance critical stuff and prototypes supporting
everything else. So, I see this PySqueak work as being a step into that
future of Prototypes and types, but I'm working on the Prototype side, not
to slight the types side. OCaml and relatives seems to have that nailed,
because they are able to infer types, so you get the benefits of types
without as much syntactic clutter. And clutter means programs that are
harder to read and thus harder to maintain (which is why Java fails as a
productive language in practice, even when you have tools to write the
boilerplate for you; we really need a tool for Java that hides all that).

But, still, to agree with your sentiment, who would want to use a buggy
new system that in addition to all of Python's warts (*)
   http://www.amk.ca/python/writing/warts
then adds in on top of that new paradigms and other clutter to learn? And
makes difficult to use the old ways, which are well documented and well
known? That is always the inventors or innovators' dilemma. There is
always a strong constituency for the status quo, and so a new idea has
many strong enemies and few half-hearted friends. And I think that is
one reason I tend to start over from scratch on language projects; if no
one is going to use it, then I might as well write it the way I want it to
work then adopt someone else's compromises and legacy choices (which even
they may no longer be happy with). On the other hand, progress is often
most quickly made by focusing on one specific issue (though not always),
so in this case focusing on prototypes gets me more mileage than focusing
on syntax (which is the hardest thing for most people to learn it seems).

Having agreed somewhat, still, as one inventor (Edison?) was quoted:
"What is the value of a new baby?"

Python as it is solves whole classes of problems well (text processing,
file handling, sockets, gluing C libraries, but lots more).
Still, it has weaknesses, especially for entry-level GUI programming.
Compare it to HyperCard which met many of CP4E's goals twenty years ago:
     From: http://en.wikipedia.org/wiki/HyperCard
"HyperCard was a huge hit almost instantly. Many people who thought they
would never be able to program a computer started using HyperCard for all
sorts of automation and prototyping tasks, a surprise even to its
creator." Or from:
   http://www.wired.com/news/mac/0,2125,54365,00.html
"The result is both simple and powerful. Fifth-graders get to grips with
HyperCard in minutes, building databases of their Pokemon cards. Cyan, the
game publisher, used it to create fiendishly complex games like Myst and
Riven."

Makes me wonder why Python is still struggling with questions of what is
the best GUI development tool for it? Or why we think CP4E is needed given
Python exists? Is just a better IDLE what it is all about? What is
missing? PythonCard is a great step in the right direction. But, I think
part of what is missing in Python is the prototype-like notions which are
behind HyperCard or Self, or even Delphi or VB GUI development, to a 
lesser extent. (HyperCard has a English-like language too, but
I'll ignore that here, taking a more formal programming language syntax as
a given.) Python also fails in practice with modifying programs while they 
run, which becomes a big issue for intermediate-level programs and their 
programmers.

In this case, here are two big arguments for "Self" and a
prototype oriented mindset. One issue it tries to address is something
that by now you may take for granted but may still be a stumbling block
for new programmers, which is how people usually reason from particular to
general. And so they may be better off learning to program a particular
object then to program a class of objects. So, in Logo, teaching "Fred"
how to draw a spiral may be easier than thinking about a "Fred" class of
objects that all draw spirals. You say Python has an easy paradigm to
learn, but I think that is not quite true. Python has many inconsistencies
and warts (consider the fraction email I just posted) and is approachable
to many people in part precisely because they learned C or BASIC first
(e.g. infix functional notation), and are looking for something better and
more fun and powerful. (**) I feel adding stronger support for Prototypes, 
if not at the language level then at the tools and library level, would 
potentially help make Python more approachable for beginners. And I think 
the Self claims are in that direction. Still, Self is not the only 
approach to prototypes, see for example:
   http://www.dekorte.com/docs/protos/
And consider the statement there: "Prototype-based languages are object 
oriented languages where a new object instance is "cloned" from existing 
live object (a prototype) instead of being constructed by a class. This 
makes the language simpler by requiring one less data type and solving the 
infinite regress problem of classes (if you use a class to create an 
object, what do you use to create a class?). It is also ideal for systems 
such as GUIs where the pattern of creating one object by copying and 
modifying another is already handled by the language itself."

The second big area is the "fragile base class problem" or more generally
the issue that people want to customize their images or programs, yet that
messes up anyone else who want to import the code. By having a culture of
working with prototypes, one is more used to customizing specific set ups,
and then having tools which help one integrate customizations. One is more
used to splitting off a set of base classes and doing different things
with them in an experimental ways, then all the careful work that goes
into maintaining one common set of classes (Even if ultimately one may
prefer to minimized the number of base classes one works with). I think 
work in that direction is a way to get the benefits of something like 
Squeak as a platform without all the drawbacks of continually having old 
code fail with every new small release.

Still, in Python's defense (or condemnation :-) in practice it doesn't
have a class side equivalent to Smalltalk. You can make one using wrapper
functions, and you can use shared class variables, but in general, Python
programs don't do things in the class way Smalltalk does. And since much
Python code is written in text editors, there is also not the issue of a
class side / instance side set of two buttons which every Smalltalk code
browser has and can lead to confusion. Python has been creeping more in a
class direction, but in practice Python code isn't written that way. So,
in that sense, Python is already a lot more Prototype oriented than
Smalltalk, plus Python supports instances having their own ad-hoc methods,
so again more prototypish. However, even if Python does support this sort
of development, in practice, Python examples are written in a more
class-oriented way. And Python tools as well. A big part of what I am
exploring right now is more how to make a library of Self-like Morph
prototypes which can be used to build interfaces in a more Self-like way.
Squeak introduced Morphs, but then made them into classes (and badly
factored ones at that), which I think lost some of the power.

By the way, here is a PataPata (PySqeuak) version that allows wx Widgets 
as Morphs (with some wrapping, which is only trivially done at this stage 
as a proof of concept for Buttons, TextEdits, and Sliders),
http://svn.sourceforge.net/viewcvs.cgi/patapata/trunk/PataPata/PataPata.py?view=log

I already have hit a wx bug with the version I use where Buttons
don't display drag feedback because they capture mouse drag events when
clicked, e.g. the same as probably here:
http://groups.google.com/group/comp.soft-sys.wxwindows/browse_thread/thread/121a5068724c613/e077cfa418cbd5d3?lnk=st&q=wxwidgets+button+mouse+events&rnum=7&hl=en#e077cfa418cbd5d3
I can drag wx sliders or text fields correctly though.
I saw the same problem when trying the latest version of PythonCard, but
now think it is wxGTK not PythonCard.

This new version uses a more generalized notion of properties than earlier
versions in order to be able to wrap foreign widgets (though not Python's
properties, which were too limited in some respects, and also would have
not worked in Jython 2.1). Still, with this wx bug (I see no way around
it, but that is par for the course when using native widgets or a C
library), plus the extra layer of indirectness wrapping in properties
requires, I am left wondering if I should just go push ahead with drawing
my own widgets, perhaps building on wx OGL or one of the other widget sets
people have made like Pyxel.
   http://bellsouthpwp.net/p/r/prochak/pyxel.html
If I do my own widgets, then I could fairly easily make everything work as 
a Jython-based Java plugin, which would be a neat deployment vehicle. And 
if I keep the advanced property support, then wx or TK widgets are always 
a possibility for someone who wants them.

--Paul Fernhout

(*) and there are several not listed there I could mention, though I still
agree with the author there that: "When viewed next to the large number of
things which Python gets right -- a small language core, strong but
dynamic typing, reuse of the idea of namespaces, always using call by
reference [I think he means value], indentation instead of delimiters --
these flaws are small ones, and I can easily live with them".

(**) For another example, if you look at it from a
documenting-intent point of view, Smalltalk's keyword syntax (e.g. Window
showAtX: 10 y: 20." ) makes reading programs much easier than reading
functional syntax where arguments have no hints (e.g. "Window.show(10,20)"
) and reading programs is what most programmer's spend most of their time
doing. :-) So, if you really want programmers to have happy lives,
teach everyone keyword syntax. :-) Of course, I am living with Python's
functional syntax in order to gain some of the other benefits of it, but
that doesn't mean I am happy about that aspect of it, or that I think it
is good for beginners either. Actually, another Python wart is that
variable names in a function definition become part of the API (e.g.
"myfunction(x=10, y=20)" which is a gross violation of the notion that a
function definition, including local variables, should be independent of
specifying how it is called.)









From pdfernhout at kurtz-fernhout.com  Fri May 26 22:03:07 2006
From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout)
Date: Fri, 26 May 2006 16:03:07 -0400
Subject: [Edu-sig] Accessibility to non CS types?
In-Reply-To: 
References: 
Message-ID: <44775EFB.6070606@kurtz-fernhout.com>

kirby urner wrote:
> Now they open a tutorial or book on such as Python, and immediately
> feel lost.  There's a lot of new jargon, and not many references to
> languages they already know.  Where is "Python for Pascal
> programmers"?

As in my longer email previous, I think part of the answer is in better 
tools and libraries, and that is why HyperCard, VB, or Delphi became 
popular. While TK is nice, not having a good generally purpose default GUI 
development system with the power of, say, Hypercard that everyone points 
to as a no-brainer for any beginner to use is a weakness from a beginner 
standpoint IMHO.

I think Self leads the way here in generality with one inspector that can 
be used to build GUIs, programs, or just sets of objects. And here is an 
attempt to bring that ease of use to Python, building on ideas from Self 
(and Squeak): :-)
http://svn.sourceforge.net/viewcvs.cgi/patapata/trunk/PataPata/PataPata.py?view=log
Doesn't succeed yet perhaps in making that beginner friendly, but a start.
(PythonCard is much better choice for current work though.)

--Paul Fernhout

From kirby.urner at gmail.com  Fri May 26 22:09:59 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Fri, 26 May 2006 13:09:59 -0700
Subject: [Edu-sig] Accessibility to non CS types?
In-Reply-To: 
References: 
	
Message-ID: 

On 5/26/06, Guido van Rossum  wrote:
> On 5/26/06, kirby urner  wrote:
> > Given Python's original goal was to be friendly to techies who are not
> > specifically computer scientists,
>
> Actually, that was ABC's goal. Python's original goal was to be a
> scripting language for people already fluent in C and sh.
>
> --
> --Guido van Rossum (home page: http://www.python.org/~guido/)
>

Oh, OK.

Not many scientists and engineers learn C or sh any more.  ABC's
developers had the right idea.

Kirby

From kirby.urner at gmail.com  Fri May 26 22:36:21 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Fri, 26 May 2006 13:36:21 -0700
Subject: [Edu-sig] Refocusing on Capabilities (was PySqueak)
In-Reply-To: <44775CB1.6030600@kurtz-fernhout.com>
References: 
	<447293E8.7030601@kurtz-fernhout.com>
	
	<44731802.5080809@kurtz-fernhout.com>
	
	<44775CB1.6030600@kurtz-fernhout.com>
Message-ID: 

On 5/26/06, Paul D. Fernhout  wrote:

> But, still, to agree with your sentiment, who would want to use a buggy
> new system that in addition to all of Python's warts (*)
>    http://www.amk.ca/python/writing/warts

Quite an old document (2003), many warts fixed.

> Still, it has weaknesses, especially for entry-level GUI programming.

I don't regard the "GUI weakness" as inherent in the Python language.

One could argue it's stronger at GUIs in the hands of a pro, because
able to work with a variety of libraries, vs. one built in solution.

Event-based GUI programming is hard to get right period.

> Makes me wonder why Python is still struggling with questions of what is
> the best GUI development tool for it?

Why do we need a "best" one?

> Or why we think CP4E is needed given Python exists?

Because languages don't just teach themselves?

> Python also fails in practice with modifying programs while they
> run, which becomes a big issue for intermediate-level programs and their
> programmers.

You're talking about event loop confusions, e.g. testing a Tk app
while running in Tk?

Using a text editor, with shell-based reload, allows GUI programs to
be debugged on the fly in my experience.

> Actually, another Python wart is that variable names in a function definition become
> part of the API (e.g. "myfunction(x=10, y=20)" which is a gross violation of the notion
> that a function definition, including local variables, should be independent of
> specifying how it is called.)

Please explain this notion further.  I thought one point of a function
definition was to define how to call it i.e. to specify what variables
to pass and how.  myfunction( ) and myfunction(4,3) would both work in
the above case -- Python is quite flexible in this way (not good?).

Kirby

From kirby.urner at gmail.com  Fri May 26 22:55:47 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Fri, 26 May 2006 13:55:47 -0700
Subject: [Edu-sig] new python // and /
In-Reply-To: <44774532.3070304@kurtz-fernhout.com>
References: <44770FA8.9090803@luc.edu> <44774532.3070304@kurtz-fernhout.com>
Message-ID: 

On 5/26/06, Paul D. Fernhout  wrote:
> I would just like to point out that Python (compared to Smalltalk)
> http://www.smalltalk.org/articles/article_20041008_a1.html
> has always done division wrong, and the new approach still does division
> wrong, IMHO, from a mathematical (not implementation) perspective.

Scheme also has a built in rational number type.  There's been some
discussion of building that in to Python, but my understanding is
that's being left to libraries at this point. We already have any
number of Rational Number implementations (I've written a few myself).

Adding a new decimal type (different from floating point) became the
focus instead (good choice of priorities IMO).

Are you subscribed to pydev by the way?  You seem inclined to redesign
Python in some fundamental way, and that's unlikely to happen as a
result of posts to edu-sig.  We tend to take Python as a given.

Kirby

From mtobis at gmail.com  Fri May 26 23:06:48 2006
From: mtobis at gmail.com (Michael Tobis)
Date: Fri, 26 May 2006 16:06:48 -0500
Subject: [Edu-sig] new python // and /
In-Reply-To: <44774532.3070304@kurtz-fernhout.com>
References: <44770FA8.9090803@luc.edu> <44774532.3070304@kurtz-fernhout.com>
Message-ID: 

I am just getting started on teaching python as a first language. (The
same course at the same university that Andy is teaching this fall,
actually.) Since the course is actually a breadth introduction to
computing as well as an introduction to programming, time is of the
essence.

My decision was to simply tell students that fractional numbers on
computers are tricky business, and that if they plan to go much
further they would have to learn about them, but that I was going to
stick to integers.

fwiw I find this to be the most cognitively accessible approach. The
advantage of Python as a first language is the minimization of
intellectual clutter. We can start with procedural knowledge and move
to semantic knowledge gradually. Avoiding the complexities of the
representation of fractional numbers seems like the best approach at
this stage.

If I had a bit longer I would still not introduce floats or decimals
or infinite precision or fraction objects or any other variation
common or obscure at least for the first few weeks.

I think it's best, at least for didactic purposes, that there is a
handy division operator that is closed on the integers, and I'd prefer
to maintain the existing behavior of operator.div when presented with
two ints.

mt

From guido at python.org  Fri May 26 23:07:21 2006
From: guido at python.org (Guido van Rossum)
Date: Fri, 26 May 2006 14:07:21 -0700
Subject: [Edu-sig] new python // and /
In-Reply-To: 
References: <44770FA8.9090803@luc.edu> <44774532.3070304@kurtz-fernhout.com>
	
Message-ID: 

On 5/26/06, kirby urner  wrote:
> Scheme also has a built in rational number type.  There's been some
> discussion of building that in to Python, but my understanding is
> that's being left to libraries at this point. We already have any
> number of Rational Number implementations (I've written a few myself).

Rationals are easy to implement and easy to understand from a
mathematical POV, but not practical when it comes to computing your
taxes. ABC used rationals and it was not a success (except amongst
mathematicians :-).

Floating point decimal is a much better choice.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

From ianb at colorstudy.com  Fri May 26 23:22:39 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Fri, 26 May 2006 16:22:39 -0500
Subject: [Edu-sig] Refocusing on Capabilities (was PySqueak)
In-Reply-To: <44775CB1.6030600@kurtz-fernhout.com>
References: 		<447293E8.7030601@kurtz-fernhout.com>				<44731802.5080809@kurtz-fernhout.com>	
	<44775CB1.6030600@kurtz-fernhout.com>
Message-ID: <4477719F.90308@colorstudy.com>

Paul D. Fernhout wrote:
> For textual statement of the key issue, see:
>    http://en.wikipedia.org/wiki/Self_programming_language
> "The problem: Traditional object languages are based on a deep-rooted 
> duality. Classes define the basic qualities and behaviours of objects, and 
> instances are a particular object based on a class. ... Unless one can 
> predict with certainty what qualities the objects will have in the distant 
> future, one cannot design a class hierarchy properly. All too often the 
> program will evolve to need added behaviours, and suddenly the whole 
> system must be re-designed (or refactored) to break out the objects in a 
> different way. Experience with early OO languages like Smalltalk showed 
> that this sort of issue came up again and again. Systems would tend to 
> grow to a point and then become very rigid, as the basic classes deep 
> below the programmer's code grew to be simply "wrong". [My note: I think 
> Squeak got to that point of rigidity long ago. :-) ] Without some way to 
> easily change the original class, serious problems could arise. ... In 
> general, such changes had to be done very carefully, as other objects 
> based on the same class might be expecting this "wrong" behavior: "wrong" 
> is often dependent on the context. ... The problem here is that there is a 
> duality, classes and instances. Self simply eliminated this duality. ... 
> This may not sound earth shattering, but in fact it greatly simplifies 
> dynamism. If you have to fix a problem in some "base class" because your 
> program has a problem, simply change it and make copies of that new object 
> instead. No other program will see this change. ... This dramatically 
> simplifies the entire OO concept as well. Everything might be an object in 
> traditional system, but there is a very fundamental difference between 
> classes and instances. In Self, there isn't."

I think there's two issues: classes and inheritance.  I don't think 
inheritance is a particularly respected structure in Python. 
isinstance() is considered poor form in many situations.  Some of 
Smalltalk's biggest sins, IMHO, come from using inheritance in clever 
ways, often to a don't-repeat-yourself end, but DRY isn't always such a 
good idea.  The fact that all the classes are opened up to you -- not 
just technical, but practically actively encouraging you to fiddle with 
them -- is not very helpful either.

So, I think Python avoids some of that fragility, and I think that's 
just as much about community sentiment as the particular things that are 
possible.  Probably Zope 2 was a big lesson for everyone who touched it 
in the perils of important and deep class hierarchies.

Inheritance is a sometimes useful implementation technique.  I think 
it's wrong to think of it as more than that.  Probably we need better 
support for some other competing techniques.  I think that would be most 
useful if they can be supported without requiring different paradigms.

So prototype-based programming and cloning might be easier described in 
a Python context as delegation (though that's not exactly right).  Or 
whatever it might be -- it doesn't need to be in conflict with what 
Python has now, because the promises are already pretty loose, and 
generally Python programmers have no problem with different object 
models.  Every so often you get someone on comp.lang.python who really 
cares about is-a vs. has-a and all that stuff, but I think that's just a 
byproduct of poor education and it wears off in time.

There's also other ways of doing this stuff out there.  Generic 
functions are a very different approach than either classes or 
prototypes.  And, ignoring some (really fairly minor) syntactic issues, 
they fit nicely in Python, right alongside other techniques.

(Live and persisten objects, however, are not such a good fit into 
Python, and maybe that's more of what you are pining for?)

>>My layman's question, after reading your posts, is:  why not just keep
>>Python pythonic and Self selfish?
>>
>>In other words, Python already has a very strong paradigm, very simple 
>>to learn.  Why mess with that?  I guess I'm a purist in that regard. 
>>But that doesn't make me a language bigot, as I fully respect the right
>>of other languages to define themselves around equally strong, yet
>>different, paradigms.  I'm also biased towards OO.

I don't see the strong paradigm you do.  Python has a bunch of 
under-appreciated functional constructs that people use a lot, but since 
they don't look Lispy people don't realize they are functional.

> Python as it is solves whole classes of problems well (text processing,
> file handling, sockets, gluing C libraries, but lots more).
> Still, it has weaknesses, especially for entry-level GUI programming.
> Compare it to HyperCard which met many of CP4E's goals twenty years ago:
>      From: http://en.wikipedia.org/wiki/HyperCard
> "HyperCard was a huge hit almost instantly. Many people who thought they
> would never be able to program a computer started using HyperCard for all
> sorts of automation and prototyping tasks, a surprise even to its
> creator." Or from:
>    http://www.wired.com/news/mac/0,2125,54365,00.html
> "The result is both simple and powerful. Fifth-graders get to grips with
> HyperCard in minutes, building databases of their Pokemon cards. Cyan, the
> game publisher, used it to create fiendishly complex games like Myst and
> Riven."

I really got to get me a copy of HyperCard, but I still can't quite 
decide what's important about it.  Anyway, it's quite possible that 
HyperCard is best seen as a constrained object model, probably much more 
constrained than prototype programming in general.  Where all your 
objects are instances of Card, for instance.

> In this case, here are two big arguments for "Self" and a
> prototype oriented mindset. One issue it tries to address is something
> that by now you may take for granted but may still be a stumbling block
> for new programmers, which is how people usually reason from particular to
> general. And so they may be better off learning to program a particular
> object then to program a class of objects. So, in Logo, teaching "Fred"
> how to draw a spiral may be easier than thinking about a "Fred" class of
> objects that all draw spirals.

Why not just use a spiral() function?  Specifically here, but also 
generally.  Functions are nice.

> The second big area is the "fragile base class problem" or more generally
> the issue that people want to customize their images or programs, yet that
> messes up anyone else who want to import the code. 

Functions are practically the pinacle of reusability.  Of course, with 
*only* functions it's not that easy to do work, lamda calculus aside.

Maybe records (objects with no methods), plus functions, extended with 
generic functions for smart polymorphism?

> (**) For another example, if you look at it from a
> documenting-intent point of view, Smalltalk's keyword syntax (e.g. Window
> showAtX: 10 y: 20." ) makes reading programs much easier than reading
> functional syntax where arguments have no hints (e.g. "Window.show(10,20)"
> ) and reading programs is what most programmer's spend most of their time
> doing. :-) So, if you really want programmers to have happy lives,
> teach everyone keyword syntax. :-) Of course, I am living with Python's
> functional syntax in order to gain some of the other benefits of it, but
> that doesn't mean I am happy about that aspect of it, or that I think it
> is good for beginners either. Actually, another Python wart is that
> variable names in a function definition become part of the API (e.g.
> "myfunction(x=10, y=20)" which is a gross violation of the notion that a
> function definition, including local variables, should be independent of
> specifying how it is called.)

File layout becomes the module structure too.  A little bit of a 
problem, but not a huge one.  I think py3k's extended signature syntax 
improves this.


From ianb at colorstudy.com  Fri May 26 23:23:56 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Fri, 26 May 2006 16:23:56 -0500
Subject: [Edu-sig] Accessibility to non CS types?
In-Reply-To: 
References: 	
	
Message-ID: <447771EC.1020905@colorstudy.com>

kirby urner wrote:
> Not many scientists and engineers learn C or sh any more.  ABC's
> developers had the right idea.

Yes, but they learn C++ and Java and things like that.  It's all part of 
the Algol family, and that family has maintained a strong hold on the 
mainstream of language syntax.

From kirby.urner at gmail.com  Fri May 26 23:40:32 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Fri, 26 May 2006 14:40:32 -0700
Subject: [Edu-sig] new python // and /
In-Reply-To: 
References: <44770FA8.9090803@luc.edu> <44774532.3070304@kurtz-fernhout.com>
	
Message-ID: 

On 5/26/06, Michael Tobis  wrote:
> My decision was to simply tell students that fractional numbers on
> computers are tricky business, and that if they plan to go much
> further they would have to learn about them, but that I was going to
> stick to integers.
>

I would not make this decision.  Floating points aren't so problematic
that we need to avoid them for several weeks.  Several minutes maybe.

Kirby

From kirby.urner at gmail.com  Fri May 26 23:42:04 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Fri, 26 May 2006 14:42:04 -0700
Subject: [Edu-sig] Accessibility to non CS types?
In-Reply-To: 
References: 
	
	
	<447771EC.1020905@colorstudy.com>
	
Message-ID: 

On 5/26/06, Ian Bicking  wrote:
> kirby urner wrote:
 > > Not many scientists and engineers learn C or sh any more.  ABC's
 > > developers had the right idea.
 >
 > Yes, but they learn C++ and Java and things like that.  It's all part of
 > the Algol family, and that family has maintained a strong hold on the
 > mainstream of language syntax.
 >


 So you're saying Python is sufficiently accessible because we may
 still assume scientists and engineers are learning C++ and Java?

 The fact remains:  many academics are throwing up their hands when
 encountering Python, because they can't make the leap from what they
 knew before.  If my sources are to be believed that is:

 http://worldgame.blogspot.com/2006/05/coffee-shop-physics.html

 Kirby

From kirby.urner at gmail.com  Fri May 26 23:54:29 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Fri, 26 May 2006 14:54:29 -0700
Subject: [Edu-sig] Refocusing on Capabilities (was PySqueak)
In-Reply-To: <4477719F.90308@colorstudy.com>
References: 
	<447293E8.7030601@kurtz-fernhout.com>
	
	<44731802.5080809@kurtz-fernhout.com>
	
	<44775CB1.6030600@kurtz-fernhout.com> <4477719F.90308@colorstudy.com>
Message-ID: 

On 5/26/06, Ian Bicking  wrote:

> I think there's two issues: classes and inheritance.  I don't think
> inheritance is a particularly respected structure in Python.

???

> Inheritance is a sometimes useful implementation technique.  I think
> it's wrong to think of it as more than that.  Probably we need better
> support for some other competing techniques.

Composition is a commonly used competing technique.  Then of course
we're free to just write functions, outside of any class.

In my thumbnail of language history, I talk about
(1) wild west spaghetti code
(2) structured programming
(3) OO
(4) design patterns.

It's very possible to write ultra-confusing OO code, so in some sense
1 is to 2 as 3 is to 4 (structured programming reformed the
spaghettifiers, while emphasis on DP corals and controls the
undisciplined OOers).

I'm sort of leaving out the evolution of functional programming in the above.

KIrby

From ianb at colorstudy.com  Sat May 27 00:26:59 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Fri, 26 May 2006 17:26:59 -0500
Subject: [Edu-sig] Refocusing on Capabilities (was PySqueak)
In-Reply-To: 
References: 	
	<447293E8.7030601@kurtz-fernhout.com>	
		
	<44731802.5080809@kurtz-fernhout.com>	
		
	<44775CB1.6030600@kurtz-fernhout.com>
	<4477719F.90308@colorstudy.com>
	
Message-ID: <447780B3.7000709@colorstudy.com>

kirby urner wrote:
> On 5/26/06, Ian Bicking  wrote:
> 
>> I think there's two issues: classes and inheritance.  I don't think
>> inheritance is a particularly respected structure in Python.
> 
> 
> ???

Inheritance as an abstraction used for communication.  In other words, 
giving someone a class and telling them to subclass it.  Also, paying 
attention to the class hierarchy when consuming objects is discouraged. 
  Actually, paying any attention to the class when consuming an object 
is discouraged.

>> Inheritance is a sometimes useful implementation technique.  I think
>> it's wrong to think of it as more than that.  Probably we need better
>> support for some other competing techniques.
> 
> 
> Composition is a commonly used competing technique.  Then of course
> we're free to just write functions, outside of any class.

Yes, that works great ;)

From mtobis at gmail.com  Sat May 27 01:21:34 2006
From: mtobis at gmail.com (Michael Tobis)
Date: Fri, 26 May 2006 18:21:34 -0500
Subject: [Edu-sig] new python // and /
In-Reply-To: 
References: <44770FA8.9090803@luc.edu> <44774532.3070304@kurtz-fernhout.com>
	
	
Message-ID: 

Kirby, I am confident you are dealing with a different population with
different interests and skills. Some of my students are taking the
course because they are math-averse, and Loyola allows the survey of
computing as a fulfillment of a math requirement in business and
liberal arts curricula INSTEAD of a conventional math course.

I am much more interested in teaching this crowd abstraction, rigor,
and orthogonality than exponents and mantissas.  I have already rocked
their boats trying to explain twos complement. I promise you these
people do not need to know what a float is and how it differs from a
mathematical real, that on the whole they are not equipped to
understand it, and that it would be a bad idea to explain it.

Generalizing from this, I suspect a big part of what makes teaching
Python such a quandary is that it is so accessible. (As with many of
its problems, c.f. "too many web frameworks", this is symptomatic of
the language's strengths, but that doesn't mean it isn't a problem)

There are diverse audiences that might be exposed, and that in turn
makes a uniform curriculum problematic.

mt

From driscollkevin at gmail.com  Sat May 27 02:07:28 2006
From: driscollkevin at gmail.com (Kevin Driscoll)
Date: Fri, 26 May 2006 20:07:28 -0400
Subject: [Edu-sig] new python // and /
In-Reply-To: 
References: <44770FA8.9090803@luc.edu> <44774532.3070304@kurtz-fernhout.com>
	
	
	
Message-ID: <87a8578e0605261707h72088bfan3e11d9878cdf8174@mail.gmail.com>

I introduce the issue of integer versus floating point division by
giving (high school) students a self-directed programming challenge
that will lead them to the head scratching conclusion that division
doesn't work exactly in the manner that they expect.  Using long
division on the board, it's pretty easy to demonstrate how integer
division and use of the modulo division complement one another.

As time is also of the essense in my course, we usually settle on the
pragmatic axiom of almost always using a floating-point divisor.

This reminds me of the recent thread regarding equal sign ambiguity.
Perhaps we could start collecting examples of familiar symbols from
mathematics that might confuse a new programmer.

Kevin Driscoll

From kirby.urner at gmail.com  Sat May 27 02:31:03 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Fri, 26 May 2006 17:31:03 -0700
Subject: [Edu-sig] new python // and /
In-Reply-To: 
References: <44770FA8.9090803@luc.edu> <44774532.3070304@kurtz-fernhout.com>
	
	
	
Message-ID: 

On 5/26/06, Michael Tobis  wrote:
> Kirby, I am confident you are dealing with a different population with
> different interests and skills. Some of my students are taking the
> course because they are math-averse, and Loyola allows the survey of
> computing as a fulfillment of a math requirement in business and
> liberal arts curricula INSTEAD of a conventional math course.
>
> I am much more interested in teaching this crowd abstraction, rigor,
> and orthogonality than exponents and mantissas.  I have already rocked
> their boats trying to explain twos complement. I promise you these
> people do not need to know what a float is and how it differs from a
> mathematical real, that on the whole they are not equipped to
> understand it, and that it would be a bad idea to explain it.

I'm not talking about getting into all the details.  Just tell 'em to
expect some weirdo rounding phenomena, odd last digits and so on,
based on the fact that Python is internally using base two when doing
decimals.  That's all you need to say.

But to eschew using floats for weeks just overdramatizes everything
and makes them averse to using a very basic and important feature of
this computer language.  That does them a disservice.  I use floats
with 8th graders immediately and have never had any problems.

> Generalizing from this, I suspect a big part of what makes teaching
> Python such a quandary is that it is so accessible. (As with many of
> its problems, c.f. "too many web frameworks", this is symptomatic of
> the language's strengths, but that doesn't mean it isn't a problem)
>

The problem with the academics Bernie talks about is no one teaches
them Python.  They're busy professionals and when they open a tutorial
they see a lot of jargon is already assumed (iterator, class,
object...).  These are proud people, very smart, so they're not about
to enroll in my 8th grade class, where all would be made clear.

> There are diverse audiences that might be exposed, and that in turn
> makes a uniform curriculum problematic.
>
> mt

I never said anything about a uniform curriculum.  I do think avoiding
floats because you think using them means explaining a lot of stuff
about mantissas is not a good approach.

However, if these are business students, then definitely get in to the
decimal class, which is designed for use with currencies (money).

Kirby

From kirby.urner at gmail.com  Sat May 27 02:35:36 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Fri, 26 May 2006 17:35:36 -0700
Subject: [Edu-sig] Refocusing on Capabilities (was PySqueak)
In-Reply-To: <447780B3.7000709@colorstudy.com>
References: 
	<447293E8.7030601@kurtz-fernhout.com>
	
	<44731802.5080809@kurtz-fernhout.com>
	
	<44775CB1.6030600@kurtz-fernhout.com> <4477719F.90308@colorstudy.com>
	
	<447780B3.7000709@colorstudy.com>
Message-ID: 

On 5/26/06, Ian Bicking  wrote:

>
> Inheritance as an abstraction used for communication.  In other words,
> giving someone a class and telling them to subclass it.  Also, paying
> attention to the class hierarchy when consuming objects is discouraged.
>   Actually, paying any attention to the class when consuming an object
> is discouraged.
>

Several important standard library modules give you the classes to
inherit from, and invite you to write your own methods.  HTML and XML
parsing for example.

I don't see where Python discourages subclassing.

Then I think you're talking about duck typing, i.e. if it behaves a
certain way, it's OK to pass, and the type checking police won't be
strict about it, like in Java.  That I understand.  However, I
wouldn't call that discouraging -- I find it encouraging myself.  Too
much type checking is a pain, and is what discourages Java use.

Kirby

From ianb at colorstudy.com  Sat May 27 03:46:48 2006
From: ianb at colorstudy.com (Ian Bicking)
Date: Fri, 26 May 2006 20:46:48 -0500
Subject: [Edu-sig] Refocusing on Capabilities (was PySqueak)
In-Reply-To: 
References: 	
	<447293E8.7030601@kurtz-fernhout.com>	
		
	<44731802.5080809@kurtz-fernhout.com>	
		
	<44775CB1.6030600@kurtz-fernhout.com>
	<4477719F.90308@colorstudy.com>	
		
	<447780B3.7000709@colorstudy.com>
	
Message-ID: <4477AF88.1020709@colorstudy.com>

kirby urner wrote:
> On 5/26/06, Ian Bicking  wrote:
> 
>>
>> Inheritance as an abstraction used for communication.  In other words,
>> giving someone a class and telling them to subclass it.  Also, paying
>> attention to the class hierarchy when consuming objects is discouraged.
>>   Actually, paying any attention to the class when consuming an object
>> is discouraged.
>>
> 
> Several important standard library modules give you the classes to
> inherit from, and invite you to write your own methods.  HTML and XML
> parsing for example.

In comparison, ElementTree does such parsing without every subclassing. 
  Those specific modules were inspired by SAX and other libraries that 
came from the Java or Smalltalk worlds.  I think over time we've found 
better ways to do these things.

> I don't see where Python discourages subclassing.

As a language, no.  As a practice, *I* certainly would discourage it 
except when used internally as an implementation detail.  Where I do use 
it, I usually dislike the result.  I think this is a shift that's 
happened many places in the Python world, though I'm sure there are 
others who would disagree.

> Then I think you're talking about duck typing, i.e. if it behaves a
> certain way, it's OK to pass, and the type checking police won't be
> strict about it, like in Java.  That I understand.  However, I
> wouldn't call that discouraging -- I find it encouraging myself.  Too
> much type checking is a pain, and is what discourages Java use.

When working with objects, yes, you shouldn't care about their class. 
At which point it's up to the implementor if they subclass an existing 
class or recreate the functionality.  I this recreation is often the 
right choice, even when it means code duplication.

-- 
Ian Bicking  |  ianb at colorstudy.com  |  http://blog.ianbicking.org

From kirby.urner at gmail.com  Sat May 27 04:19:04 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Fri, 26 May 2006 19:19:04 -0700
Subject: [Edu-sig] Refocusing on Capabilities (was PySqueak)
In-Reply-To: <4477AF88.1020709@colorstudy.com>
References: 
	
	<44731802.5080809@kurtz-fernhout.com>
	
	<44775CB1.6030600@kurtz-fernhout.com> <4477719F.90308@colorstudy.com>
	
	<447780B3.7000709@colorstudy.com>
	
	<4477AF88.1020709@colorstudy.com>
Message-ID: 

> As a language, no.  As a practice, *I* certainly would discourage it
> except when used internally as an implementation detail.

I agree that the DP (design pattern) generation is making better sense
around when to use and when not to use subclassing.  O'Reilly's 'Head
First Into Design Patterns' is a good example.  I plugged it in my
Saturday Academy class, along with TAOCP, NKS, and Zelle's Python
intro.

Here're some negative comments about this book that I liked, to help
us stay well rounded:
http://www.codinghorror.com/blog/archives/000380.html

Kirby

From kris.olson.au at gmail.com  Sat May 27 08:02:34 2006
From: kris.olson.au at gmail.com (Kris Olson)
Date: Sat, 27 May 2006 14:02:34 +0800
Subject: [Edu-sig] list newbie
Message-ID: <3dce001b0605262302g1f479858y2c693d9df08a419c@mail.gmail.com>

Hello All

I am new to teaching Python but have enjoyed the reaction of my students to
Python.  I have been using the interactive mode to demonstrate and as a tool
to check their understanding.  However, it is hard for them to see when I
get down to the bottom of the page.  Is there a way to clear the screen or
open a new interactive screen?

If not, it would be a useful tool to have.

-- 
Kris Olson
Geraldton Senior College
Head of Business and Computing Area
Curriculum Information Communication Technology Coordinator
08-9965-8443 (W)
041-792-4434 (M)
08-9965-0317 (H)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20060527/4af4032c/attachment.html 

From kirby.urner at gmail.com  Sat May 27 17:12:04 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Sat, 27 May 2006 08:12:04 -0700
Subject: [Edu-sig] list newbie
In-Reply-To: <3dce001b0605262302g1f479858y2c693d9df08a419c@mail.gmail.com>
References: <3dce001b0605262302g1f479858y2c693d9df08a419c@mail.gmail.com>
Message-ID: 

On 5/26/06, Kris Olson  wrote:
> Hello All
>
> I am new to teaching Python but have enjoyed the reaction of my students to
> Python.  I have been using the interactive mode to demonstrate and as a tool
> to check their understanding.  However, it is hard for them to see when I
> get down to the bottom of the page.  Is there a way to clear the screen or
> open a new interactive screen?

Hey Kris, I know what you mean.  Sometimes I roll up the IDLE window
so that the bottom of the frame is towards the middle of my screen.
But there might be a better solution.

Kirby

From sb at csse.unimelb.edu.au  Sat May 27 17:22:21 2006
From: sb at csse.unimelb.edu.au (Steven Bird)
Date: Sat, 27 May 2006 11:22:21 -0400
Subject: [Edu-sig] list newbie
In-Reply-To: 
References: <3dce001b0605262302g1f479858y2c693d9df08a419c@mail.gmail.com>
	
Message-ID: <97e4e62e0605270822w1b53cdceq5a3db48e29b0a12b@mail.gmail.com>

On 5/27/06, kirby urner  wrote:
> On 5/26/06, Kris Olson  wrote:
> > Is there a way to clear the screen or
> > open a new interactive screen?
>
> Hey Kris, I know what you mean.  Sometimes I roll up the IDLE window
> so that the bottom of the frame is towards the middle of my screen.
> But there might be a better solution.

I do the same thing, but its clunky and doesn't completely solve the problem.

I can think of various solutions in addition to a "clear screen" button:

a) "clear history", which leaves the interactive prompt at the top of the window

b) a scrollbar which lets you scroll down so that the only line shown
is at the very top of the window

-Steven Bird

From andre.roberge at gmail.com  Sat May 27 17:31:27 2006
From: andre.roberge at gmail.com (Andre Roberge)
Date: Sat, 27 May 2006 12:31:27 -0300
Subject: [Edu-sig] list newbie
In-Reply-To: <3dce001b0605262302g1f479858y2c693d9df08a419c@mail.gmail.com>
References: <3dce001b0605262302g1f479858y2c693d9df08a419c@mail.gmail.com>
Message-ID: <7528bcdd0605270831u23304a13o1c4df0cffd4572ee@mail.gmail.com>

On 5/27/06, Kris Olson  wrote:
>
> Hello All
>
> I am new to teaching Python but have enjoyed the reaction of my students
> to Python.  I have been using the interactive mode to demonstrate and as a
> tool to check their understanding.  However, it is hard for them to see when
> I get down to the bottom of the page.  Is there a way to clear the screen or
> open a new interactive screen?
>
> If not, it would be a useful tool to have.
>

You may also want to have a look at a little app I wrote called "Lightning
Compiler".  It includes a standard Python interpreter but also a Python
aware editor in  which you can enter code, click a button (or use a keyboard
shortcut) and see the output in a separate window pane. With the editor, you
can also run doctests - which is a good tool to check students
understanding.
It can be found under lightning here:
https://sourceforge.net/project/showfiles.php?group_id=125834
It requires wxPython though...

Andr?

-- 
> Kris Olson
> Geraldton Senior College
> Head of Business and Computing Area
> Curriculum Information Communication Technology Coordinator
> 08-9965-8443 (W)
> 041-792-4434 (M)
> 08-9965-0317 (H)
>
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20060527/2c1b0322/attachment.htm 

From andre.roberge at gmail.com  Sun May 28 16:43:48 2006
From: andre.roberge at gmail.com (Andre Roberge)
Date: Sun, 28 May 2006 11:43:48 -0300
Subject: [Edu-sig] Accessibility to non CS types?
In-Reply-To: 
References: 
	
	
	<447771EC.1020905@colorstudy.com>
	
	
Message-ID: <7528bcdd0605280743m16748b5euc2b73622021ef435@mail.gmail.com>

On 5/26/06, kirby urner  wrote:
>
>
> So you're saying Python is sufficiently accessible because we may
> still assume scientists and engineers are learning C++ and Java?
>
> The fact remains:  many academics are throwing up their hands when
> encountering Python, because they can't make the leap from what they
> knew before.
>

If I may, I'd like to start with a brief personal history to introduce what
I see as two barriers to learning Python for "scientists/academics".

I learned FORTRAN in 1977 in a College-level course (pre-University in
Quebec).  I then went to University to study Physics.  During my
undergraduate degree, I wrote perhaps 3 (short) computer programs.  Still,
FORTRAN was easily understood as the stuff I did was mostly numerical work.
*The concepts and language I had learned in Physics were easily adaptable in
FORTRAN.*

While in graduate school, I bought a PC and learned some basic C
programming, mostly for fun.  Again, I didn't write many programs, and they
weren't very long.  It did prepare me for what was to come.  *The transition
from FORTRAN and C was fairly easy, as I could write FORTRAN-style programs
in C ;-).

As a Physics prof, I wanted to introduce visual tools to my students.  After
learning about Java Applets, I decided that they were an ideal tool.  So, I
set up to learn enough Java to write my own applets for physics demo.  I
wrote a grand total of perhaps 10 applets over the course of 3 years, in
between teaching and doing research.  This was around 1995.

The first barrier I encountered was the "dot" notation.  Nowhere did I see
it explain separately, as a notational convention, shared by many
languages.  I thought it was something weird about Java that I would have to
learn.

Solution: introduce the dot notation totally separately from the other
programming syntax.  This is something I tried to do in one rur-ple lesson.

The second barrier I found was the insistance on categorizing relationships
in terms of "is-a" and "has-a".  The examples that I would find most natural
to look at were often counterintuitive.  I remember in particular seeing
that programming examples that use the relationships between a circle and an
ellipse (or a rectangle and a square) seemed to have the relationship going
backwards.

Let me give a concrete example explaining inheritance for non-computer
scientists.
===
class Father(object):
    def __init__(self):
        self.eye_colour = "blue"
    def greets(self):
        print "Hello there!"

class Mother(object):
    def __init__(self):
        self.eye_colour = "brown"

class Child(Mother, Father):
    pass

Sally = Child()
print Sally.eye_colour
Sally.greets()
===
The computer scientists in the (virtual) room are probably horrified.  A
Child is not a Mother, nor a Father and you do not have the proper "is-a"
relationship.  Yet, I would claim that the above example would be very
appropriate for the average person.  Sally inherit brown eyes for her
mother, not because brown is the dominant gene (as in biology) in this case,
but because of the inheritance order.  (Interchange Mother and Father in the
class Child and Sally will have blue eyes)

Words like "inheritance" have been borrowed and adapted by computer
scientists for use in their own discipline.  They have been borrowed because
they were familiar words that conveyed (partly) the concept used in the
scientific discipline.  They have been adapted because the usual definition
was not technically correct.  I believe that teaching those concepts should
go through the same process: start with the familiar (but slightly
incorrect) use of the word, and refine later on.

This, btw, is how I use to teach about "work" in physics, so I have some
idea about the possible use of this approach..  If I ask my son to carry the
groceries bags from the car to the kitchen (essentially at the same
horizontal level), he will not believe me if I tell him that he did no
work.   Yet, he would have done no work (W=0) [against gravity], as every
physics textbook would tell you.

==
As a final point about the personal history: after not having done any
programming for about 8 years (and having never written any significant
computer program), I decided to learn Python as a hobby with the goal to
eventually teach my kids.  By then, I had some idea about the dot notation,
so this barrier was easily overcome.  Python tutorials that I skimmed
through did not insist on the importance of "is-a" and "has-a" relationship,
so I didn't feel constrained in how I set up the relationships between the
classes I wrote.  I was free to explore (and make mistakes!) and it was
fun!  It still is.

Andr?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20060528/854e5ff3/attachment.html 

From johannes.wollard at gmail.com  Sun May 28 18:59:36 2006
From: johannes.wollard at gmail.com (Johannes Woolard)
Date: Sun, 28 May 2006 17:59:36 +0100
Subject: [Edu-sig] Elementary graphics library
Message-ID: <10c99c2a0605280959n5481b536ue71f28153447a897@mail.gmail.com>

As part of my Summer of Code proposal, I said i would write a simple
graphics library.
I've spent the last couple of hours brainstorming this, and written it all up:

http://crunchy.python-hosting.com/wiki/GraphicsDoc.

If anyone has any comments/ideas I would love to hear them!

Johannes

-- 
Johannes Woolard,
Oriel College, Oxford
OX1 4EW
07837880296
ox extn: 26611

From kirby.urner at gmail.com  Sun May 28 19:17:16 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Sun, 28 May 2006 10:17:16 -0700
Subject: [Edu-sig] Accessibility to non CS types?
In-Reply-To: <7528bcdd0605280743m16748b5euc2b73622021ef435@mail.gmail.com>
References: 
	
	
	<447771EC.1020905@colorstudy.com>
	
	
	<7528bcdd0605280743m16748b5euc2b73622021ef435@mail.gmail.com>
Message-ID: 

On 5/28/06, Andre Roberge  wrote:

> The first barrier I encountered was the "dot" notation.  Nowhere did I see
> it explain separately, as a notational convention, shared by many languages.
>  I thought it was something weird about Java that I would have to learn.
>
> Solution: introduce the dot notation totally separately from the other
> programming syntax.  This is something I tried to do in one rur-ple lesson.
>

I very much agree.  I even go so far as to phase dot notation into
standard mathematics, as another way to express such concepts as
mytriangle.A (returns a degree measure).  Use dot notation even
without reference to any specific computer language, but with
reference to the OO paradigm ("math as extensible type system" meme).

> The second barrier I found was the insistance on categorizing relationships
> in terms of "is-a" and "has-a".  The examples that I would find most natural
> to look at were often counterintuitive.  I remember in particular seeing
> that programming examples that use the relationships between a circle and an
> ellipse (or a rectangle and a square) seemed to have the relationship going
> backwards.
>
> Let me give a concrete example explaining inheritance for non-computer
> scientists.
> ===
> class Father(object):
>     def __init__(self):
>         self.eye_colour = "blue"
>     def greets(self):
>          print "Hello there!"
>
> class Mother(object):
>     def __init__(self):
>         self.eye_colour = "brown"
>
> class Child(Mother, Father):
>     pass
>
> Sally = Child()
>  print Sally.eye_colour
> Sally.greets()
> ===
> The computer scientists in the (virtual) room are probably horrified.  A
> Child is not a Mother, nor a Father and you do not have the proper "is-a"
> relationship.  Yet, I would claim that the above example would be very
> appropriate for the average person.  Sally inherit brown eyes for her
> mother, not because brown is the dominant gene (as in biology) in this case,
> but because of the inheritance order.  (Interchange Mother and Father in the
> class Child and Sally will have blue eyes)
>
> Words like "inheritance" have been borrowed and adapted by computer
> scientists for use in their own discipline.  They have been borrowed because
> they were familiar words that conveyed (partly) the concept used in the
> scientific discipline.  They have been adapted because the usual definition
> was not technically correct.  I believe that teaching those concepts should
> go through the same process: start with the familiar (but slightly
> incorrect) use of the word, and refine later on.

Yes.  This is characteristic of many disciplines; they absorb from
ordinary language, but pretty soon stop paying their debt, i.e. stop
building on-ramps.  Instead, they close off and fortify, so that those
not "in the know" sound like fools to the ears of insiders.  It's a
kind of corruption really.  My buddy Ed Applewhite had 'Layman'
printed on his business card, kind of a warning that he was nobody's
fool (yet he often pretended he couldn't quite follow).

> This, btw, is how I use to teach about "work" in physics, so I have some
> idea about the possible use of this approach..  If I ask my son to carry the
> groceries bags from the car to the kitchen (essentially at the same
> horizontal level), he will not believe me if I tell him that he did no work.
>   Yet, he would have done no work (W=0) [against gravity], as every physics
> textbook would tell you.

Yes, "work" is especially problematic, as it only counts if against
the vectors you consider worthy.  Irrelevant vectors, though
resistent, don't bar the way to "getting the job done" (at least not
directly), so you can go down fighting, working like crazy, yet the
physicist will tell you you're doing no work whatsoever (like the
burglar fumbling with the safe combo is doing no work, if the police
come too soon).

> ==
> As a final point about the personal history: after not having done any
> programming for about 8 years (and having never written any significant
> computer program), I decided to learn Python as a hobby with the goal to
> eventually teach my kids.  By then, I had some idea about the dot notation,
> so this barrier was easily overcome.  Python tutorials that I skimmed
> through did not insist on the importance of "is-a" and "has-a" relationship,
> so I didn't feel constrained in how I set up the relationships between the
> classes I wrote.  I was free to explore (and make mistakes!) and it was fun!
>  It still is.
>
> Andr?
>

Useful autobio.  I used to strongly encourage Arthur to switch into
this mode from time to time.  That's related to your earlier remarks
about academic jargons:  we're each a walking namespace (Pythonic
concept), yet sometimes forget that fact (fish unaware of water).
When you go into autobio, people get a better idea of how to factor
out various biases you may never be free of in this life (because they
define you as a person e.g. "fought in 'Nam for eight years").

Your discussion of how is-a versus has-a easily confounds is quite
useful.  And I don't think CS has earned the right to claim it has
this all nailed down, simply because it requires knowledge of specific
knowledge domains to really come up with the most intuitive and simple
designs.  Physicists need to absorb OO and decide for themselves, not
leaving it to CS types to decide how to organize all those bosons and
leptons (although I'm sure CERN welcomes the various proposals -- HTTP
was invented to help keep track of 'em all).

Kirby

From Scott.Daniels at Acm.Org  Sun May 28 20:07:38 2006
From: Scott.Daniels at Acm.Org (Scott David Daniels)
Date: Sun, 28 May 2006 11:07:38 -0700
Subject: [Edu-sig] list newbie
In-Reply-To: <3dce001b0605262302g1f479858y2c693d9df08a419c@mail.gmail.com>
References: <3dce001b0605262302g1f479858y2c693d9df08a419c@mail.gmail.com>
Message-ID: 

Kris Olson wrote:
> I am new to teaching Python but have enjoyed the reaction of my students to
> Python.  I have been using the interactive mode to demonstrate.... it is hard for 
 > them to see when I get down to the bottom of the page.
 > Is there a way to clear the screen or open a new interactive screen?

Here's a trick I use for myself when the shell screen gets too full:

1) Make sure another window is open (do File / New Window if needed).
2) Close the shell screen.
3) On (one of) the open window(s) do Windows / Python Shell.

You now have a nice clean window.

I agree it would be nice to be able to prune the shell window
contents.  Especially if you have output some long text w/o
returns in it, scrolling can get painfully slow as the output
accumulates.

-- Scott David Daniels
Scott.Daniels at Acm.Org


From pdfernhout at kurtz-fernhout.com  Sun May 28 22:31:01 2006
From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout)
Date: Sun, 28 May 2006 16:31:01 -0400
Subject: [Edu-sig] Elementary graphics library
In-Reply-To: <10c99c2a0605280959n5481b536ue71f28153447a897@mail.gmail.com>
References: <10c99c2a0605280959n5481b536ue71f28153447a897@mail.gmail.com>
Message-ID: <447A0885.6060001@kurtz-fernhout.com>

If you haven't already, you could check out:

Pyxel
   http://bellsouthpwp.net/p/r/prochak/pyxel.html
   "Pyxel is a python library that provides a dynamic, interactive, highly 
portable, graphical environment.  It makes diagrams and widgets look 
identical in whatever underlying environment it supports."

wxOGL
   http://wiki.wxpython.org/index.cgi/wxOGL
   "The OGL library was originally written in C++ and provided to wxPython 
via an extension module wrapper as is most of the rest of wxPython. The 
code has now been ported to Python (with many thanks to Pierre Hj?lm!) in 
order to make it be more easily maintainable and less likely to get rusty 
because nobody cares about the C++ lib any more."
   (bottom of that pages has more alternatives, like the next)

Piddle
   http://piddle.sourceforge.net/
"PIDDLE is a Python module for creating two-dimensional graphics in a 
manner that is both cross-platform and cross-media; that is, it can 
support screen graphics (e.g. QuickDraw, Windows, Tk) as well as file 
output (PostScript, PDF, GIF, etc.). It makes use of the native 2D drawing 
calls of each backend, for maximum efficiency and quality. It works by 
defining a base class (piddle.Canvas) with methods for all supported 
drawing primitives. A particular drawing context is provided in the form 
of a derived class. PIDDLE applications will be able to automatically 
select an appropriate backend for the user's environment. "

and of course PyGame or PySDL or even the OpenGL Canvas stuff (there are 
probably more) for ideas and to see what others have done before in pure 
Python and you could possibly build on. Or even PyGeo if your focus is 
mainly on geometry instead of arbitrary 2D graphics (I wasn't sure).

There are a lot of charting and plotting and other graphics packages out 
there with Python bindings (including Cairo, which you are looking at as 
your first backend target). You can ask yourself if a newer API really 
gets you that much over these existing things? Will it really be that much 
simpler once you really try to make it useful? And if you have a 
crossplatform backend already like Cairo or wx, does it gain you that much 
to abstract above that if can you simplify it somehow, versus just make a 
simple interface to one cross-platform library (which may be hard enough)?

Now, it still might be worth doing for you even if the answers are no, but 
to maximize your effectiveness it is nice go in with your eyes open about 
whether you are doing this to learn and to have fun, to improve an 
existing thing, or to make something new that fills an empty niche (or to 
try do do all three); that is a question I often wrestle with for my own 
projects. :-)

--Paul Fernhout


Johannes Woolard wrote:
> As part of my Summer of Code proposal, I said i would write a simple
> graphics library.
> I've spent the last couple of hours brainstorming this, and written it all up:
> 
> http://crunchy.python-hosting.com/wiki/GraphicsDoc.
> 
> If anyone has any comments/ideas I would love to hear them!
> 
> Johannes
> 


From sb at csse.unimelb.edu.au  Sun May 28 22:39:02 2006
From: sb at csse.unimelb.edu.au (Steven Bird)
Date: Sun, 28 May 2006 16:39:02 -0400
Subject: [Edu-sig] list newbie
In-Reply-To: 
References: <3dce001b0605262302g1f479858y2c693d9df08a419c@mail.gmail.com>
	
Message-ID: <97e4e62e0605281339g4b7f42b4k5b52fff8d07717bc@mail.gmail.com>

On 5/28/06, Scott David Daniels  wrote:
> Here's a trick I use for myself when the shell screen gets too full:
>
> 1) Make sure another window is open (do File / New Window if needed).
> 2) Close the shell screen.
> 3) On (one of) the open window(s) do Windows / Python Shell.
>
> You now have a nice clean window.

But then you lose the session.  You could recover the session by
re-entering the necessary lines (e.g. importing modules, defining
variables), but that leaves us with the original problem...

-Steven Bird

From peter at mapledesign.co.uk  Sun May 28 22:46:33 2006
From: peter at mapledesign.co.uk (Peter Bowyer)
Date: Sun, 28 May 2006 21:46:33 +0100
Subject: [Edu-sig] Accessibility to non CS types?
In-Reply-To: <447771EC.1020905@colorstudy.com>
References: 
	
	
	<447771EC.1020905@colorstudy.com>
Message-ID: <7.0.1.0.0.20060528214022.036a1c80@mapledesign.co.uk>

At 22:23 26/05/2006, Ian Bicking wrote:
> > Not many scientists and engineers learn C or sh any more.  ABC's
> > developers had the right idea.
>
>Yes, but they learn C++ and Java and things like that.

You wish.  As part of my project I did a brief survey of what physics 
departments used to teach programming (research that didn't make it 
into the final report due to space).  Most offered only an 
introductory course, often less than 1 lab a week for 10 weeks.  C 
was still popular (as was Fortran) but I argue that due to the lack 
of time the scientists and engineers don't learn these languages, 
they learn enough to complete the exercises to finish the 
course.  Not because they're inherantly lazy, but because there's way 
too much material to cover in the pitifully small time allocated.

I wish it were different, but despite computational work being one of 
the important methods of research in physics, programming is not seen 
as a key part of a physics degree.  And I thorougly concur with the 
comment about it being taught by the previous generation: many who 
were in charge of teaching or planning the computer modules had been 
using computers in the 1960's - which doesn't make it wrong, but 
provides a different outlook on today's systems.

Peter


From peter at mapledesign.co.uk  Sun May 28 23:39:52 2006
From: peter at mapledesign.co.uk (Peter Bowyer)
Date: Sun, 28 May 2006 22:39:52 +0100
Subject: [Edu-sig] Accessibility to non CS types?
In-Reply-To: <447B63F1.1010208@stargate.net>
References: 
	
	
	<447771EC.1020905@colorstudy.com>
	<7.0.1.0.0.20060528214022.036a1c80@mapledesign.co.uk>
	<447B63F1.1010208@stargate.net>
Message-ID: <7.0.1.0.0.20060528223823.035db850@mapledesign.co.uk>

At 22:13 29/05/2006, Bill Bradley wrote:
>         Good gravy?!  Where did you look?  When I got my Physics 
> degree we not only had to take programming, but we built 68K 
> breadboard computers, programmed them in assembly (with a hex 
> keypad) and used them to read and drive ADC/DACs to output on 
> 'scopes.  And no that was not during the Dark Ages, I got my degree 
> in the 90s.

Round most of the physics departments in the UK, where course details 
were available to the public via their websites.  Do check back - 
does your physics department still do it, or has it fallen by the 
wayside as students arrive knowing less physics, so more 'core' 
material has to be crammed into the 3 years of a Bachelor's degree?

Peter


From francois.schnell at gmail.com  Mon May 29 00:00:53 2006
From: francois.schnell at gmail.com (francois schnell)
Date: Mon, 29 May 2006 00:00:53 +0200
Subject: [Edu-sig] Accessibility to non CS types?
In-Reply-To: <44775EFB.6070606@kurtz-fernhout.com>
References: 
	<44775EFB.6070606@kurtz-fernhout.com>
Message-ID: <13a83ca10605281500h67954015w85cd3f3b4cbca2f1@mail.gmail.com>

On 26/05/06, Paul D. Fernhout  wrote:
>
>
> I think Self leads the way here in generality with one inspector that can
> be used to build GUIs, programs, or just sets of objects. And here is an
> attempt to bring that ease of use to Python, building on ideas from Self
> (and Squeak): :-)
>
> http://svn.sourceforge.net/viewcvs.cgi/patapata/trunk/PataPata/PataPata.py?view=log
> Doesn't succeed yet perhaps in making that beginner friendly, but a start.
> (PythonCard is much better choice for current work though.)


Hello,

I've just gave a try to your "PataPata" and I already have fun with it while
"testing" it :)
http://francois.schnell.free.fr/bazar/patapata-test1/patapata-test1.html

Will it be possible to directly add new methods to morphs (maybe from the
inspector ? ... when I saw the 'grow' method I wanted a "shrink' one ...).
Is there a way yet to execute a Morph method from another Morph (if I click
on Morph 1 I'd like to execute method X from Morph 2 for example).

I find your "PataPata"  promising and I'm eager to see how it evolves :)

francois



--Paul Fernhout
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20060529/e683ee8f/attachment.html 

From Scott.Daniels at Acm.Org  Mon May 29 00:27:52 2006
From: Scott.Daniels at Acm.Org (Scott David Daniels)
Date: Sun, 28 May 2006 15:27:52 -0700
Subject: [Edu-sig] Accessibility to non CS types?
In-Reply-To: <7528bcdd0605280743m16748b5euc2b73622021ef435@mail.gmail.com>
References: 			<447771EC.1020905@colorstudy.com>		
	<7528bcdd0605280743m16748b5euc2b73622021ef435@mail.gmail.com>
Message-ID: 

Andre Roberge wrote:
> ... Let me give a concrete example explaining inheritance for non-computer
> scientists.
> ===
> class Father(object): ...
> class Mother(object): ...
> 
> class Child(Mother, Father): ...
> ===
> The computer scientists in the (virtual) room are probably horrified.  

Yup.  I am aghast.  You are using the "built-from" relationship.  For
yourself this is fine, but pedagogically it leads to very bad habits.
The reason I am appalled is that I have maintained code that was written
this way, and the mess that results over years of extending from such
a shaky foundation is scary.

> I would claim the above example would be appropriate for the average person.

I claim this is because you are a scientist, not a mathematician.  At
Penn, Mathematics was an Art, not a Science (I have great sympathy for
that classification).  You are in the habit of lying to your students
and, next course, telling them "you know, what you learned in the
previous course was wrong."  This is a reason for people leaving the
sciences.  Mathematicians tend to try to stick to truths, though they
expand the universe they talk about each time.  In part this distinction
in approaches makes sense because mathematicians who make mistakes are
corrected (and scorned) by other mathematicians, while physicists are
corrected by reality (and refine their models).

Computer Science is a funny field, reached from both mathematics and
engineering, so the ideas you see there can come from either of these
sides (and cause lovely fights in faculty meetings).  I consider CompSci
an architecture-like discipline, with mathematics holding the position
in CompSci that physics has in architecture.

> Words like "inheritance" have been borrowed and adapted by computer
> scientists for use in their own discipline.
While words like "spin" for physicists....  Natural languages seldom
have precise definitions, and Computer Science is not close to the
worst offender in this respect.

To follow up on Kirby's personal history suggestion:  I was a math
loving kid by fourth grade, came to computers by accident in summer
after 9th grade (in 1966) doing machine language on a vacuum tube
computer (LGP-30).  The following summer I spent full-time in an
NSF-sponsored class at Penn where we a language a week for the summer
(two programs per language).  The experience gave me a good feel for
what a programming language is in general, as well as specifically.

I decided around 1972 (after auditing a class or two from Knuth) that
I could be either a mediocre mathematician or a very good computer
programmer.  Twenty years ago I went back to school to attempt a PhD
as a teaching union card in CompSci, and got a "drop-out masters."
For my research I was trying to do Query Optimization in Object-Oriented
Databases, and glanced briefly at Python (the type system did not fit my
research needs).  After working in compilers and Databases after school,
I picked up Python as a way of pursuing a long-running personal project,
and had the most fun I've had in a new language in 30 years.

--Scott David Daniels
Scott.Daniels at Acm.Org


From andre.roberge at gmail.com  Mon May 29 01:06:14 2006
From: andre.roberge at gmail.com (Andre Roberge)
Date: Sun, 28 May 2006 20:06:14 -0300
Subject: [Edu-sig] Accessibility to non CS types?
In-Reply-To: 
References: 
	
	
	<447771EC.1020905@colorstudy.com>
	
	
	<7528bcdd0605280743m16748b5euc2b73622021ef435@mail.gmail.com>
	
Message-ID: <7528bcdd0605281606x32c22e6aq968b7602ace8c476@mail.gmail.com>

On 5/28/06, Scott David Daniels  wrote:
>
> Andre Roberge wrote:
> > ... Let me give a concrete example explaining inheritance for
> non-computer
> > scientists.
> > ===
> > class Father(object): ...
> > class Mother(object): ...
> >
> > class Child(Mother, Father): ...
> > ===
> > The computer scientists in the (virtual) room are probably horrified.
>
> Yup.  I am aghast.  You are using the "built-from" relationship.  For
> yourself this is fine, but pedagogically it leads to very bad habits.


Agreed ... when it comes to teaching computer science, to future computer
scientist.  I was reacting to some comment (including reading from a
different thread) about how scientists were not able to grasp Python and OOP
(to paraphrase the argument).

Python is being used in bioinformatics - and some biologists are introduced
to computer programming for the first time through their interest in
molecular biology, dna structure and the like.  I would argue that using an
example as the one above would help lowering the barrier to learning, which
is something important when people think they can't do it.

The reason I am appalled is that I have maintained code that was written

> this way, and the mess that results over years of extending from such
> a shaky foundation is scary.
>
> > I would claim the above example would be appropriate for the average
> person.
>
> I claim this is because you are a scientist, not a mathematician.  At
> Penn, Mathematics was an Art, not a Science (I have great sympathy for
> that classification).  You are in the habit of lying to your students
> and, next course, telling them "you know, what you learned in the
> previous course was wrong."


Actually, I'm a theoretical physicist and as such I am closer in my approach
to mathematicians than to experimental physicists.  When I was teaching, I
tried to be careful to mention every time a simplification was made and
pointing out that a "deeper truth" would be learned about later.  I don't
mean to sound defensive: I was truly doing this - but without giving it much
more thought than this.  However, I think your characterisation of the
average physicist's teaching is quite accurate!

This is a reason for people leaving the
> sciences.


Proof?  :-)

Mathematicians tend to try to stick to truths, though they
> expand the universe they talk about each time.  In part this distinction
> in approaches makes sense because mathematicians who make mistakes are
> corrected (and scorned) by other mathematicians, while physicists are
> corrected by reality (and refine their models).


Well put.

[snip]
> > Words like "inheritance" have been borrowed and adapted by computer
> > scientists for use in their own discipline.
> While words like "spin" for physicists....  Natural languages seldom
> have precise definitions, and Computer Science is not close to the
> worst offender in this respect.


And I never meant to imply it was.  In fact, I provided a similar example
for physics ("work").

To me, the most important thing is to get students (non computer scientists)
interested in learning about programming, a bit like you might get someone
interested in learning French by taking them to a night club in Montreal:
they might pick up some inappropriate sentence constructions (that would
appall your average French linguist) which will need to be corrected later
... but chances are they will want to learn French a lot more than if they
would have been put in a class taught by your average French linguist.

Andr?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20060528/89ac6a8d/attachment.html 

From delza at livingcode.org  Mon May 29 02:55:46 2006
From: delza at livingcode.org (Dethe Elza)
Date: Sun, 28 May 2006 17:55:46 -0700
Subject: [Edu-sig] Elementary graphics library
In-Reply-To: <447A0885.6060001@kurtz-fernhout.com>
References: <10c99c2a0605280959n5481b536ue71f28153447a897@mail.gmail.com>
	<447A0885.6060001@kurtz-fernhout.com>
Message-ID: <24d517dd0605281755k72986ee2ye0822b8993a77f41@mail.gmail.com>

On 5/28/06, Paul D. Fernhout  wrote:
> If you haven't already, you could check out:

Also:

PIL.ImageDraw
    http://www.esrf.fr/computing/bliss/python2/pil/PIL.ImageDraw.html
    http://www.pythonware.com/library/pil/handbook/imagedraw.htm
    "The ImageDraw module provide simple 2D graphics for Image
objects. You can use this module to create new images, annotate or
retouch existing images, and to generate graphics on the fly for web
use."

Aggdraw
    http://effbot.org/zone/draw-agg.htm
    "The aggdraw module implements the basic WCK 2D Drawing Interface
on top of the AGG library. This library provides high-quality drawing,
with anti-aliasing and alpha compositing, while being fully compatible
with the WCK renderer."

Matplotlib
    http://matplotlib.sourceforge.net/
    "matplotlib is a python 2D plotting library which produces
publication quality figures in a variety of hardcopy formats and
interactive environments across platforms. matplotlib can be used in
python scripts, the python and ipython shell (ala matlab or
mathematica), web application servers, and six graphical user
interface toolkits."

Kiva
   http://code.enthought.com/kiva/
   "Kiva is a multi-platform DisplayPDF drawing engine that supports
multiple output backends, including Windows, GTK, and Macintosh native
windowing systems, a variety of raster image formats, PDF, and
Postscript."

DrawBot/NodeBox (OS X only, but useful as examples of simple 2D systems)
    http://drawbot.com/index.html
    http://nodebox.net/manual/reference/topics.php
    "DrawBot is an powerful, free application for MacOSX that invites
you to write simple Python scripts to generate two-dimensional
graphics. The builtin graphics primitives support rectangles, ovals,
(bezier) paths, polygons, text objects and transparency."

PyCairo
    http://cairographics.org/pycairo
    "Cairo is a library for drawing vector graphics. Vector graphics
are interesting because when they appear on screen, they don't lose
clarity when resized or transformed."

--Dethe

From pdfernhout at kurtz-fernhout.com  Mon May 29 19:35:46 2006
From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout)
Date: Mon, 29 May 2006 13:35:46 -0400
Subject: [Edu-sig] Accessibility to non CS types?
In-Reply-To: <13a83ca10605281500h67954015w85cd3f3b4cbca2f1@mail.gmail.com>
References: 	<44775EFB.6070606@kurtz-fernhout.com>
	<13a83ca10605281500h67954015w85cd3f3b4cbca2f1@mail.gmail.com>
Message-ID: <447B30F2.60806@kurtz-fernhout.com>

Francois-

Wow!  Thanks for making that Flash recording:
   http://francois.schnell.free.fr/bazar/patapata-test1/patapata-test1.html
That is a neat demo showing things I had not even thought of, like with 
the jumping Morphs (and far beyond my presentation skills). My wife is now 
finally impressed somewhat with what I am doing. :-) The version you are 
using did benefit from her trying an earlier version and her feedback on 
it, as several things she (also a programmer) tried that were hard or 
confusing or generated errors, I made easier or fixed.

Your presentation almost made me think of one of Alan Kay's Squeak demos. 
Perhaps your familiarity with Squeak made is easier to understand what I 
was attempting with PataPata (especially without any tutorial documents)? 
Now that you made a video, perhaps that spark of enlightenment will 
spread. :-)

To answer your first question: To add a method, try right-clicking in the 
yellow inspector pane to get a menu which will allow you to make new child 
or sibling nodes of a prototype you are inspecting (or to copy, rename or 
delete a node). [Unless that is a bug under wx on your XP? system?] (I 
used to have a help text about the right click menu but it got dropped a 
while back.) "Child" nodes are children of the node you have selected, 
usually you want to create a "sibling" node if you have already clicked on 
a method or value of a Morph or Prototype you are interested in.

To make a new method, you enter the name of the new field in the first 
popup box. Then after clicking OK there, a second popup box comes up where 
you need to enter "method" without the quotes, and after you click OK 
there you can modify the default method text in the edit window below the 
yellow inspector pane. You need to enter "method" as otherwise the system 
will try to evaluate what you enter, which by default is a string. It's a 
bit awkward to use the popups (as opposed to, say, a custom new value 
entry dialog with radio buttons for method, string, or expression type), 
but it was easy to implement as a first try.

While it is more prone to error, instead of typing "method", you could 
also enter a PrototypeMethod constructor to evaluate as an expression, 
such as:
   PrototypeMethod(None, "def foo(self): print 'foo'")
which I just tested by adding a foo field to Morph 0 and then entering the 
following in the PyShell (the scrolling window at the bottom):
   world.morphs[0].foo()
which should print "foo". Not sure how robust this second approach is 
though; some tricky things happen with how PrototypeMethods are bound to 
instances which I still need to clean up;  I still need to resolve a bug 
related to copying morphs with local methods where modifying the original 
sometimes modifies the copy.

To answer your second question: To execute a method in another morph, you 
must first have a pointer to that morph directly. Ideally, that would be 
supported by cut and paste in the inspector, but you can't do that yet. 
However, you can, say, go to Morph 0 and add a field and call it "morph1" 
and then when asked for the value, enter (without quotes): 
"world.morphs[1]" which will evaluate to Morph 1 in the world. Then you 
could reference "self.morph1" in any method of Morph 0, like to call 
"self,morph1.X()" directly. I just tried that, adding
"self.morph1.x += 10" to the mouseDown method of Morph 0, so now you can 
click on Morph 0 and Morph 1 moves (what I guess might be your intent, 
based on your demo?) You could also just reference "self.world.morphs[1]" 
directly in your methods, but if you add or delete morphs in the world, 
then the morph that position 1 of that list refers to might change.

I'm guessing you're using WinXP? Nice to see the wxWindows button dragging 
properly. Under wx GTK 2.6 there is a library bug where a button only 
moves when you let go of it as it; otherwise the button eats all mouse 
events after you click in it until you release it; PythonCard has the same 
issue under GNU/Linux witht hat GTK version; one reason I am considering 
drawing my own widgets.

So many times one does things and thinks no one notices or cares, so I'm 
very excited to see someone trying it (and going to the effort to make a 
Flash video, too). Thanks again for trying it and the encouragement. As 
regards future evolution, right now I'm at a decision point as to whether 
to push forward in Python further or, as per my previous discussions here 
with Kirby where he rightly points to dominant paradigms in specific 
languages, to jump to something like OCaml and use it to build a Self-like 
prototype language on top of it (something like io, which looks great,
   http://www.iolanguage.com/about/
but with a Smalltalk/Self-derived keyword syntax, which I feel is 
desirable), and so essentially producing a system that supports two 
extremes of permissiveness at two different levels -- strong (but 
implicit) typing at a speedy supporting layer and anything-goes prototypes 
above that for most GUI development work. On the other hand, I am making a 
lot of progress with Python (and not knowing OCaml much) and a Python 
version has value to me for other reasons. So, this seems like a big vote 
on keeping it all in Python for now?

All the best.

--Paul Fernhout

francois schnell wrote:
> On 26/05/06, Paul D. Fernhout  wrote:
> 
>>
>>
>> I think Self leads the way here in generality with one inspector that can
>> be used to build GUIs, programs, or just sets of objects. And here is an
>> attempt to bring that ease of use to Python, building on ideas from Self
>> (and Squeak): :-)
>>
>> http://svn.sourceforge.net/viewcvs.cgi/patapata/trunk/PataPata/PataPata.py?view=log 
>>
>> Doesn't succeed yet perhaps in making that beginner friendly, but a 
>> start.
>> (PythonCard is much better choice for current work though.)
> 
> 
> 
> Hello,
> 
> I've just gave a try to your "PataPata" and I already have fun with it 
> while
> "testing" it :)
> http://francois.schnell.free.fr/bazar/patapata-test1/patapata-test1.html
> 
> Will it be possible to directly add new methods to morphs (maybe from the
> inspector ? ... when I saw the 'grow' method I wanted a "shrink' one ...).
> Is there a way yet to execute a Morph method from another Morph (if I click
> on Morph 1 I'd like to execute method X from Morph 2 for example).
> 
> I find your "PataPata"  promising and I'm eager to see how it evolves :)
> 
> francois
> 
> 
> 
> --Paul Fernhout


From kirby.urner at gmail.com  Mon May 29 19:48:39 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Mon, 29 May 2006 10:48:39 -0700
Subject: [Edu-sig] Accessibility to non CS types?
In-Reply-To: 
References: 
	
	
	<447771EC.1020905@colorstudy.com>
	
	
	<7528bcdd0605280743m16748b5euc2b73622021ef435@mail.gmail.com>
	
Message-ID: 

> Computer Science is a funny field, reached from both mathematics and
> engineering, so the ideas you see there can come from either of these
> sides (and cause lovely fights in faculty meetings).

Plus I'm this philo guy, stoked on Wittgenstein, coming to CS through
software engineering (Bucciarelli, MIT, is also an LW head I'm told),
and providing perhaps unwelcome (at least to established CSers) new
underpinnings, in the form of "language games".[1]

Philosophy is perennially showing up at the door with new base
classes, or more likely with claims that these classes were inherent
all along ("nothing really new since Plato"), but are now need of
maintenance (updates), perhaps an expensive overhaul.

Sophists maybe got a bad name for such door-to-door tactics, but, per
Pirsig's 'Zen...', the fact is, many did quality work and what we call
"rationality" no doubt owes plenty to these pre-Socratics.[2]

This move (coming to CS through philosophy) allows me to compete with
the more ordinary logical notations, but with OO, claiming OO is far
ahead of the Bertrand Russell era logicians and their propositional
descendants when it comes to fulfilling Leibnizian dream of machine
executable pattern languages.

The only reason OO hasn't made more inroads in K12 by now is
mathematicians wall out what they can't find a way to claim credit for
(I'm talking about an inferior brand of credit-hungry math head, not
top-of-the-line math people like Conway and Guy).

Back to inheritance, it's simply not the case that we only inherit
because of an is-a relationship.  We're always pouring in mixins, or
in Java, interfaces, which merely bolt on some common API, such as a
dial pad or other familiar widget set (a "dashboard" or "cockpit" of
controls and instruments, bells and whistles).

One could argue that composition would be the better approach but, in
Java anyway, we're interested in the gatekeeping and error trapping
functions of type checking.  We use it for quality control.  Unless
you (an instance of some class) support interfaces A, B and C, no way
may you pass yourself off as type X.

Failure to support some interface'd be like a Wild West sheriff who
can't handle a gun.  Sure, pistol packing is more a mixin in this
design, but it's also part of a sheriff's basic identity.  Without
that interface, you're just a wannabee.

In Python, we don't have interfaces per se (thanks in part to multiple
inheritance), and duck typing means we postpone a lot of the critical
gatekeeping until runtime.  Here you are, your first day on the job as
sheriff, in your Wild West saloon (off duty let's say).  Someone comes
through those swinging door thingys and says "Draw!" and you can't,
because you don't have a gun API.  An exception is raised.

Python programmers get used to catching such exceptions while testing
and won't release code that breaks in this way.  Java programmers rely
on their compiler to catch a lot of such problems even before runtime.
 We hope they also do a lot of runtime testing, because a green light
from the compiler doesn't mean your customer will be satisfied (gee,
wouldn't that have been nice?).

So there's a different feel to the debugging process in the two
languages, as a result of this difference in emphasis.  Bruce Eckel
talks a lot about this difference.[3]

Kirby

[1] http://mail.python.org/pipermail/edu-sig/2001-March/001030.html (autobio)
[2] http://en.wikipedia.org/wiki/Zen_and_the_Art_of_Motorcycle_Maintenance
(pirsig)
[3] http://www.mindview.net/WebLog/log-0025 (eckel)

From kirby.urner at gmail.com  Mon May 29 22:32:00 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Mon, 29 May 2006 13:32:00 -0700
Subject: [Edu-sig] More OO chatter from the Edubuntu box
Message-ID: 

So I'm in my basement, vertically under mom's office, separated by a
wall from the living room stereo, which is playing pirate music on the
CD player (a local band).

Amy and the girls are in the kitchen doing tie-die.  My wife is in the
hospital, with an expected discharge date of the day after tomorrow.
I ferry people to and fro quite often (we just came from there).

Yesterday the girls and I went to Lloyd Center (Nixon as VP:
"America's answer to communism"), to view 'Over the Hedge', which I
promptly reviewed in my blog.
http://mybizmo.blogspot.com/2006/05/over-hedge-movie-review.html

Last night, we projected 'March of the Penguins' (en version) using my
small footprint projector, against the living room wall (the one above
my head).  I'd seen it before, but watched most of it again (it's a
good story).

I'm using Edubuntu on Derek's refurbished Compaq Deskpro, using a
Buffalo game port to convert between ethernet and 801.11g.  I have two
access points in my house, although the second one is easily portable,
as it takes IP over AC (any AC socket I plug the thing into is
transformed into a wireless station).

I speak of home architecture with a reason:  'The Sims' has kids in
the mood to think like sociologist engineers, which adults always
consider vaguely threatening at best (given the connotations of
"social engineering" -- but what is "legislation" if not that?).
Rather than fight giving them responsibilities, I want them to have
really good tools and plenty of access to global data, so that their
engineering might rock (vs. suck).

That's a motivation for pushing OO into 8th grade:  algebra alone just
ain't good enough any more.  By they time they reach college, teachers
will assume already built-in Pythonic abilities, or something similar.
 This project, I take it, is consistent with the philosophy behind
CP4E.  What better way to make OO prevalent than to phase dot notation
into algebra class?  I think my Algebra City colleagues will approve.

When I introduce OO in 8th grade, it's in terms of home blueprints
(class definitions) sourcing home instances (actual boxes, the
occasionial off-beat dome, scattered about town).  You might instance
the same blueprint in Hillsboro or Gresham I tell 'em (referencing
locales they've likely heard of -- no Devonshire around here).

I think using the home as a paradigm class is propitious, as there's
lots of implied complexity, especially once HVAC and AC/DC become a
focus (lots of APIs).  You have the media room, the pantry, the
scullery -- the whole pattern language of places.  The Sims gives us
visuals.  OO gives us implementations.

Another good thing about houses is they're in the middle in some way.
They're child nodes in neighborhood systems, rural or urban, in some
globalized humanity, plus they're parents to microbes, dust mites, all
sorts of stuff zooming in.  We're in that sweet spot between two
alienating sizes:  the too big and the too small for humans to feel
comfortable in, other than indirectly, through instrumentation,
libraries and so on.

Humans like a scenario Universe, a world of storytelling, of soaps, of
myth and history, of fact and fiction.  Which is where movies like
'Over the Hedge' come in (or 'Toy Story' or 'Shrek').  They're works
in the humanities, part of the main stream.  We like to leave the more
infra and ultra to the specialists, to the engineers.

Also about houses:  there's that excellent book wherein families have
accepted an invitation to disgorge the contents of their homes for a
photographer's compilation.   -- a coffee table book showing houses +
contents from around the world.  I'd like to project these pictures in
my Pythonic mathematics classes (seeking permission).

In sum, although I'm aware that adults dislike being captured and
modeled inside simulations sometimes, consider it patronizing to be
"planned for", to have their environments changed around them, I think
we all recognize that nature rearranges the scenery all the time
(personal note:  my dad was an urban, regional and education system
planner).

We adapt as a species, and what that feels like internally is some
"government at work" (or some other cyberia (steering committee)).
And we don't always feel good about all the changes  (even if it
tastes good, it might not be good for us) -- and we should by all
means attend to these sensations, these intuitions.  Like, don't
ignore your own internal guidance system.  On the contrary, that's
what your democracy depends on.

As an adaptable species, we're really *meant* to think hard about our
choices.  We really *do* have to work, even if we make it be playful.
It's really not a free ride.  Lots of very traditional theology could
attach at this point I realize, but I'm just operating within my
philosophy here, taking advantage of my 12 degrees of freedom.

Our planet never just "settles down" -- hence the classic next program
after "hello world" in many cases: "I'd like it to stop now, I'd like
to get off."

Or as Martin Heidegger might have put it: "how did it get to be
runtime already?"

Kirby

From kirby.urner at gmail.com  Mon May 29 22:43:39 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Mon, 29 May 2006 13:43:39 -0700
Subject: [Edu-sig] More OO chatter from the Edubuntu box
In-Reply-To: 
References: 
Message-ID: 

> Amy and the girls are in the kitchen doing tie-die.  My wife is in the
> hospital, with an expected discharge date of the day after tomorrow.
> I ferry people to and fro quite often (we just came from there).

Note that it's not my intention to be anti-social in the basement.
I'm keeping Sarah (the dog) company, as she's not welcome in tie-die
circules, where she might well make a mess.

I've just been to the supermarket (more OO [1]), where we swiped out a
couple gallons of root beer and some ice cream ("root beer floats").
This isn't suburbia, but the food situation is likewise resolved (we
have more than enough).

Now, I need to go tie-die (Sarah has relocated to the upstairs and is quiet).

Kirby

[1] http://controlroom.blogspot.com/2006/02/boosting-bandwidth.html

Also, I mentioned Bucciarelli recently.  Related blog post:
http://controlroom.blogspot.com/2006/05/isepp-lecture-end-of-season.html

From francois.schnell at gmail.com  Tue May 30 00:48:38 2006
From: francois.schnell at gmail.com (francois schnell)
Date: Tue, 30 May 2006 00:48:38 +0200
Subject: [Edu-sig] Accessibility to non CS types?
In-Reply-To: <447B30F2.60806@kurtz-fernhout.com>
References: 
	<44775EFB.6070606@kurtz-fernhout.com>
	<13a83ca10605281500h67954015w85cd3f3b4cbca2f1@mail.gmail.com>
	<447B30F2.60806@kurtz-fernhout.com>
Message-ID: <13a83ca10605291548k2619608bx5a4a42a5a1922c32@mail.gmail.com>

On 29/05/06, Paul D. Fernhout  wrote:
>
> Francois-
>
> Wow!  Thanks for making that Flash recording:
>
> http://francois.schnell.free.fr/bazar/patapata-test1/patapata-test1.html
> That is a neat demo showing things I had not even thought of, like with
> the jumping Morphs (and far beyond my presentation skills).


Well what I''m doing here is not really a "neat" presentation it's just that
when I find something interesting like this I like to show it to other
people :)  (I'm also very much into Free Culture and Free Software
advocating).

My wife is now
> finally impressed somewhat with what I am doing. :-) The version you are
> using did benefit from her trying an earlier version and her feedback on
> it, as several things she (also a programmer) tried that were hard or
> confusing or generated errors, I made easier or fixed.


Oh , send also to her "mes homages" and congratulations from the french man
:) (my English spouse still have nearly no idea what I'm doing with
electronics bits and computers all over the place).


> To answer your first question: To add a method, try right-clicking in the
> yellow inspector pane [...]
>

Dear me ... I didn't think you already have that and didn't try ... it works
great thanks ! fun times ahead :)

To answer your second question: To execute a method in another morph, you
> must first have a pointer to that morph directly. Ideally, that would be
> supported by cut and paste in the inspector, but you can't do that yet.
> However, you can, say, go to Morph 0 and add a field and call it "morph1"
> and then when asked for the value, enter (without quotes):
> "world.morphs[1]" which will evaluate to Morph 1 in the world. Then you
> could reference "self.morph1" in any method of Morph 0, like to call
> "self,morph1.X()" directly.[...]


Great my objects can now talk to each others ! It will be awesome when
you'll also have "quick integration" of this. :) More fun times ahead :))


> I'm guessing you're using WinXP? Nice to see the wxWindows button dragging
> properly.


I'm mainly using  XP for software  I don't  have  on my  Ubuntu Dapper
(like quick sreencasting, itunes/podcasts for my ipod, etc). I have one
screen/keyboard/mouse and a switch quickly between the Linux and XP box.

So many times one does things and thinks no one notices or cares, so I'm
> very excited to see someone trying it (and going to the effort to make a
> Flash video, too). Thanks again for trying it and the encouragement.


Well ... maybe it's why Einstein said it's difficult for people to
understand what they never experienced (ie in our case a visual hands-on
squeak-like familiarity of objects land) , that's also why he said that
imagination is more important than knowledge. I believe it's Alan Kay who
said that the computer revolution haven't started yet in education and that
kids ~need "imagination amplifiers" => make PataPata a good imagination
amplifier !


> As
> regards future evolution, right now I'm at a decision point as to whether
> to push forward in Python further or, as per my previous discussions here
> with Kirby where he rightly points to dominant paradigms in specific
> languages, to jump to something like OCaml and use it to build a Self-like
> prototype language on top of it (something like io, which looks great,
>    http://www.iolanguage.com/about/
> but with a Smalltalk/Self-derived keyword syntax, which I feel is
> desirable), and so essentially producing a system that supports two
> extremes of permissiveness at two different levels -- strong (but
> implicit) typing at a speedy supporting layer and anything-goes prototypes
> above that for most GUI development work. On the other hand, I am making a
> lot of progress with Python (and not knowing OCaml much) and a Python
> version has value to me for other reasons. So, this seems like a big vote
> on keeping it all in Python for now?


Well I don't know OCaml and io but If I were you I would be suspicious of a
"yankee" advising you a language written by french people ;)

I personally would *love* if you continue this in Python, I'm not anymore in
a testing phase, I've seen enough to "adopt" it and see how I can use it for
games/simulations/teaching and help where I can :)

I probably won't be able to help on the core "PataPata"  but my Python
skills gets better and better (I'm quite new to Python).

I can help with :
- bug tracking
- playing with it and doing short examples/demos (games/simulations)
- promoting and doc (especially in the French Python sphere)
- i18n and French translation
- I begin to know more and more the multimedia part of Python (sound, video,
streaming), could be handy one day
- extend morphs to the analog world (data acquisition and automation)
- I'm good at testing plenty of things and finding gems (useful if you don't
want  to reinvent the wheel). :)

Well it's bed time on this part of the globe =>  $ python dreamland.py

Please keep up your excellent work  and use Python :)


francois

All the best.
>
> --Paul Fernhout
>
> francois schnell wrote:
> > On 26/05/06, Paul D. Fernhout  wrote:
> >
> >>
> >>
> >> I think Self leads the way here in generality with one inspector that
> can
> >> be used to build GUIs, programs, or just sets of objects. And here is
> an
> >> attempt to bring that ease of use to Python, building on ideas from
> Self
> >> (and Squeak): :-)
> >>
> >>
> http://svn.sourceforge.net/viewcvs.cgi/patapata/trunk/PataPata/PataPata.py?view=log
> >>
> >> Doesn't succeed yet perhaps in making that beginner friendly, but a
> >> start.
> >> (PythonCard is much better choice for current work though.)
> >
> >
> >
> > Hello,
> >
> > I've just gave a try to your "PataPata" and I already have fun with it
> > while
> > "testing" it :)
> > http://francois.schnell.free.fr/bazar/patapata-test1/patapata-test1.html
> >
> > Will it be possible to directly add new methods to morphs (maybe from
> the
> > inspector ? ... when I saw the 'grow' method I wanted a "shrink' one
> ...).
> > Is there a way yet to execute a Morph method from another Morph (if I
> click
> > on Morph 1 I'd like to execute method X from Morph 2 for example).
> >
> > I find your "PataPata"  promising and I'm eager to see how it evolves :)
> >
> > francois
> >
> >
> >
> > --Paul Fernhout
>
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20060530/935ba35a/attachment-0001.html 

From kirby.urner at gmail.com  Tue May 30 06:09:59 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Mon, 29 May 2006 21:09:59 -0700
Subject: [Edu-sig] Accessibility to non CS types?
In-Reply-To: <13a83ca10605291548k2619608bx5a4a42a5a1922c32@mail.gmail.com>
References: 
	<44775EFB.6070606@kurtz-fernhout.com>
	<13a83ca10605281500h67954015w85cd3f3b4cbca2f1@mail.gmail.com>
	<447B30F2.60806@kurtz-fernhout.com>
	<13a83ca10605291548k2619608bx5a4a42a5a1922c32@mail.gmail.com>
Message-ID: 

On 5/29/06, francois schnell  wrote:
> On 29/05/06, Paul D. Fernhout  wrote:
>
> > Francois-
> >
> > Wow!  Thanks for making that Flash recording:
> >

I echo my thanks.  These kinds of video demos with audio are very useful.

I'm pleased you have become so enthusiastic about Paul's work.

Kirby

From pdfernhout at kurtz-fernhout.com  Tue May 30 10:13:59 2006
From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout)
Date: Tue, 30 May 2006 04:13:59 -0400
Subject: [Edu-sig] Accessibility to non CS types?
In-Reply-To: <13a83ca10605291548k2619608bx5a4a42a5a1922c32@mail.gmail.com>
References: 	<44775EFB.6070606@kurtz-fernhout.com>	<13a83ca10605281500h67954015w85cd3f3b4cbca2f1@mail.gmail.com>	<447B30F2.60806@kurtz-fernhout.com>
	<13a83ca10605291548k2619608bx5a4a42a5a1922c32@mail.gmail.com>
Message-ID: <447BFEC7.8050605@kurtz-fernhout.com>

Francois-

Well, then Python it is for as long as it works(*). :-) Thanks for the 
feedback on that.  [ (*)I know what I'm doing with __setattr_ and 
_getattribute_ must almost certainly be reducing performance by at least a 
10x order of magnitude, but so far I have not noticed... ]

And thanks for more kind words and offer of help. And anything you want to 
do to contribute would be wonderful, especially in terms of early feedback 
and later making documentation especially when the system settles down a 
bit (including perhaps a movie of yours for SourceForge? Or even a main 
page?). As for promotion, I don't want too many users just yet with the 
system in its early stages and still subject to major changes before it 
settles down (why I have not announced it to the general Python list), but 
in the long term that would be great. What a young project needs most is a 
handful of very interested people such as yourself, so low key recruiting 
like that even now would be wonderful. Also, if after using it a bit you 
decide to make a roughly prioritized list of desirable minor changes, that 
would help too.

Here is a new release as a zip file with a few files in it.
http://sourceforge.net/project/showfiles.php?group_id=165910&package_id=188385&release_id=420989
Or:
http://svn.sourceforge.net/viewcvs.cgi/patapata/trunk/releases/PataPata_v101.zip?view=log
This is mainly to fix some bugs I introduced when adding properties and wx 
widget support which prevented properly loading and saving world defining 
Python files. Files should now save and load correctly again (I noticed 
you did not show that in your movie :-). A big change from before is that 
I finally split up the single file into three files -- one for the GUI, 
one for the Example World and one for the Prototype library classes (which 
is why it is now in a zip file which expands to a directory). I also 
changed how the world file is loaded, from an eval to an import statement 
(which means the world files need to be in your Python path I think, or 
the local directory).

I also added a license.txt file clearly stating the current work is under 
the GPL (meaning applications written with it would also be under the 
GPL). Still, my intent down the road is that if there is any small pieces 
of core technology in PataPata that would make sense to be in the core 
Python distribution (like improvements to Python or Jython so they 
supported prototypes in a better way, or perhaps support related to hooks 
for networked debugging and such), those parts would (if all relevant 
contributors agree) be dual licensed under the latest Python license as 
well as the GPL. However, I think a lot of the system will end up GPL, 
including all the self-drawn widgets. I know the GPL precludes adoption by 
certain developers and uses, but I think it also is desirable by certain 
others including because it solves certain coordination issues as a sort 
of project constitution. Looking at the licenses you or Ian or some others 
posting here (e.g. Art's PyGeo) have chosen I think GPL should work out 
well enough for making a free educational platform (especially given that 
the more general programming skills kids learn with it are usable on any 
Python application). Also, it allows me to draw from GPL-d code such as 
from some GPL's parts of GNU Smalltalk or the GPL'd Pyxel (widgets in 
Python) which might help speed development of some parts and otherwise 
would be precluded if I did not go with the GPL.

A next goal is then to get some more widgets working (buttons, edit 
fields, bitmaps) and support basic HyperCard-like functionality, and do a 
simple card stack (possibly Bucky Fuller, but could be other topics; if 
you have a specific simulation idea or topic area you would like to see, I 
could make some widgets to support that). Important to this is supporting 
a system of nested views of some widgets inside another (or even nested 
worlds). Someday, perhaps even converting a lot of the examples from 
PythonCard might be a goal, so it makes sense early on to draw from 
PythonCard as much as possible, especially some of their naming conventions.

Using properties, the system can now wrap wxWidgets (or perhaps TK, not 
that I have tried that), and while that is useful, right now I just don't 
think I want to focus on that. Or to look at it from another point of 
view, what's the point of making a RAD (Rapid Application Development) 
system if I am just going to use it to wrap wxPython wrappers for 
wxWidgets (which is tedious)?  Building widgets its itself a good test of 
what the system can do and motivates further work on it. And if I develop 
new widgets using a few primitive operations based around BitBlit (or 
other simple drawing) like Squeak does it (drawing on whatever I can find 
on the web that uses Python) then I can probably also get them running 
under Jython without too much trouble, which means they could run as a 
Java applet. [Although something like Cairo might not be accessible to an 
Applet?] Basically, that is a Squeak-like approach, sending in mouse and 
key events into a world of custom Morphs. So I plan to pull out the 
wrapped wxButton and go to pure Morphs pretty soon. Still, it was worth it 
to actually wrap a few wxWidgets because that caused the improvements in 
the property system. Should doing the basic widgets prove too difficult, 
then I can fall back on wrapping wxWidgets or TK widgets or even GTK 
widgets etc.

If you know of any GPL compatible sources of widget sets in Python to draw 
from, that could really help a lot in terms of minimizing wheel 
reinvention (Dethe just posted some which I need to look at). Right now 
I'm thinking of PythonCard for the event naming structure, and maybe Pyxel 
and OcempGUI and GNU Smalltalk for some implementation ideas. The GUI uses 
wx right now, but I've been musing over using Cairo or something like it 
instead -- but it would be best if whatever is used can work both in 
Python and in a Jython Applet (either as a simple layer written for 
PataPata that works on both, or as one library like Cairo that might work 
in both). For now, my default is to just do some basic drawing with wx and 
then port it to Jython/Swing at some point.

I also have a few more things I want to add to properties from Smalltalk, 
mostly automatically tracking dependencies and sending changed messages, 
but more on that if/when I get to that.

You wrote: "make PataPata a good imagination amplifier !" That sounds like 
a good concept to always keep in mind as it develops.

All the best.

--Paul Fernhout
By the way, I was the one mentioning Ocaml :-) though I mainly see it as a 
"much better C" than something I want to be coding in all of the time. I 
prefer Smalltalk-like and Self-like systems with dynamic objects, 
including Python, but that's because, except for coding the VM or certain 
libraries, I am more interested in changing the system while it runs (like 
Smalltalk & Python can) than having the fastest system (like OCaml & C 
can). Naturally, for other people working on other problems (especially 
numerically oriented-ones), their priorities may differ.

francois schnell wrote:
> On 29/05/06, Paul D. Fernhout  wrote:
> 
>>
>> Francois-
>>
>> Wow!  Thanks for making that Flash recording:
>>
>> http://francois.schnell.free.fr/bazar/patapata-test1/patapata-test1.html
>> That is a neat demo showing things I had not even thought of, like with
>> the jumping Morphs (and far beyond my presentation skills).
> 
> 
> 
> Well what I''m doing here is not really a "neat" presentation it's just 
> that
> when I find something interesting like this I like to show it to other
> people :)  (I'm also very much into Free Culture and Free Software
> advocating).
> 
> My wife is now
> 
>> finally impressed somewhat with what I am doing. :-) The version you are
>> using did benefit from her trying an earlier version and her feedback on
>> it, as several things she (also a programmer) tried that were hard or
>> confusing or generated errors, I made easier or fixed.
> 
> 
> 
> Oh , send also to her "mes homages" and congratulations from the french man
> :) (my English spouse still have nearly no idea what I'm doing with
> electronics bits and computers all over the place).
> 
> 
>> To answer your first question: To add a method, try right-clicking in the
>> yellow inspector pane [...]
>>
> 
> Dear me ... I didn't think you already have that and didn't try ... it 
> works
> great thanks ! fun times ahead :)
> 
> To answer your second question: To execute a method in another morph, you
> 
>> must first have a pointer to that morph directly. Ideally, that would be
>> supported by cut and paste in the inspector, but you can't do that yet.
>> However, you can, say, go to Morph 0 and add a field and call it "morph1"
>> and then when asked for the value, enter (without quotes):
>> "world.morphs[1]" which will evaluate to Morph 1 in the world. Then you
>> could reference "self.morph1" in any method of Morph 0, like to call
>> "self,morph1.X()" directly.[...]
> 
> 
> 
> Great my objects can now talk to each others ! It will be awesome when
> you'll also have "quick integration" of this. :) More fun times ahead :))
> 
> 
>> I'm guessing you're using WinXP? Nice to see the wxWindows button 
>> dragging
>> properly.
> 
> 
> 
> I'm mainly using  XP for software  I don't  have  on my  Ubuntu Dapper
> (like quick sreencasting, itunes/podcasts for my ipod, etc). I have one
> screen/keyboard/mouse and a switch quickly between the Linux and XP box.
> 
> So many times one does things and thinks no one notices or cares, so I'm
> 
>> very excited to see someone trying it (and going to the effort to make a
>> Flash video, too). Thanks again for trying it and the encouragement.
> 
> 
> 
> Well ... maybe it's why Einstein said it's difficult for people to
> understand what they never experienced (ie in our case a visual hands-on
> squeak-like familiarity of objects land) , that's also why he said that
> imagination is more important than knowledge. I believe it's Alan Kay who
> said that the computer revolution haven't started yet in education and that
> kids ~need "imagination amplifiers" => make PataPata a good imagination
> amplifier !
> 
> 
>> As
>> regards future evolution, right now I'm at a decision point as to whether
>> to push forward in Python further or, as per my previous discussions here
>> with Kirby where he rightly points to dominant paradigms in specific
>> languages, to jump to something like OCaml and use it to build a 
>> Self-like
>> prototype language on top of it (something like io, which looks great,
>>    http://www.iolanguage.com/about/
>> but with a Smalltalk/Self-derived keyword syntax, which I feel is
>> desirable), and so essentially producing a system that supports two
>> extremes of permissiveness at two different levels -- strong (but
>> implicit) typing at a speedy supporting layer and anything-goes 
>> prototypes
>> above that for most GUI development work. On the other hand, I am 
>> making a
>> lot of progress with Python (and not knowing OCaml much) and a Python
>> version has value to me for other reasons. So, this seems like a big vote
>> on keeping it all in Python for now?
> 
> 
> 
> Well I don't know OCaml and io but If I were you I would be suspicious of a
> "yankee" advising you a language written by french people ;)
> 
> I personally would *love* if you continue this in Python, I'm not 
> anymore in
> a testing phase, I've seen enough to "adopt" it and see how I can use it 
> for
> games/simulations/teaching and help where I can :)
> 
> I probably won't be able to help on the core "PataPata"  but my Python
> skills gets better and better (I'm quite new to Python).
> 
> I can help with :
> - bug tracking
> - playing with it and doing short examples/demos (games/simulations)
> - promoting and doc (especially in the French Python sphere)
> - i18n and French translation
> - I begin to know more and more the multimedia part of Python (sound, 
> video,
> streaming), could be handy one day
> - extend morphs to the analog world (data acquisition and automation)
> - I'm good at testing plenty of things and finding gems (useful if you 
> don't
> want  to reinvent the wheel). :)
> 
> Well it's bed time on this part of the globe =>  $ python dreamland.py
> 
> Please keep up your excellent work  and use Python :)
> 
> 
> francois
> 
> All the best.
> 
>>
>> --Paul Fernhout

From pdfernhout at kurtz-fernhout.com  Tue May 30 20:18:05 2006
From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout)
Date: Tue, 30 May 2006 14:18:05 -0400
Subject: [Edu-sig] Elementary graphics library
In-Reply-To: <24d517dd0605281755k72986ee2ye0822b8993a77f41@mail.gmail.com>
References: <10c99c2a0605280959n5481b536ue71f28153447a897@mail.gmail.com>	
	<447A0885.6060001@kurtz-fernhout.com>
	<24d517dd0605281755k72986ee2ye0822b8993a77f41@mail.gmail.com>
Message-ID: <447C8C5D.2050506@kurtz-fernhout.com>

My head is spinning. :-)

Especially as I am contemplating backend issues for PataPata / PySqueak.

Some more things I've come across building on your search:

The obvious in retrospect:
   http://www.python.org/doc/faq/gui.html
    Python Graphic User Interface FAQ

=== a wx issue and plug for Cairo

http://wiki.osafoundation.org/pub/Journal/PhilippeBossutNotes/TheFrameworkIssue.htm
"Chandler is developed in Python and uses wxPython/wxWidgets as its 
crossplatform UI framework. The decision to use wxWidgets has been made 
early in the project and needs to be reevaluated against progress in 
competing frameworks. The goal of this document is to continue observing 
advances in other frameworks as well as learn from what we had to go 
through in developing with wxWidgets for Chandler."
Related to:
http://lists.freedesktop.org/archives/cairo/2005-July/004549.html
"I've been trying to figure out if there is a way of using Cairo with
wxPython. I've found some old conversations (over a year old) on this
list but I'm curious if anyone can point me to some actual bindings or
instructions? We're struggling with the wx graphics primitives on the
Chandler and Cairo looks like a  answer to our prayers..."

And:
   http://matplotlib.sourceforge.net/faq.html#WHICHBACKEND

====== At length:

"Which backend should I use?

Each of the backends offers different strengths. I'll summarize some of them.
Image generation
For pure image generation (no GUI) you can choose from the Agg, Cairo, PS, 
SVG, Paint, GD or EMF backends. At this point, I advise people to use the 
agg backend because:

     * it's the fastest
     * it uses freetype2 (as does GD) which renders nicely even at small 
resolutions
     * there are clipping issues with GD and Paint
     * it supports fast antialiased drawing and alpha blending
     * it supports mathtext
     * it supports images with imshow

It is likely that with time many of these limitiations or problems will be 
fixed on the other backends.

For publication submission or use with TeX, however, the postscript 
backend is naturally a good choice.
GUI
Currently there are several choices for GUIs: GTK, GTKAgg, GTKCairo, WX, 
WXAgg, TkAgg and FltkAgg, with different advantages.

     * Speed: TkAgg and GTKAgg are likely to be the fastest since most of 
Agg is renderered in C extension code
     * Stability: GTK was the first backend and thus has been most 
thoroughly vetted for bugs. The GTKAgg and GTKCairo backends reuse the GTK 
widget code, so should likewise be quite stable
     * Interactivity: All of the GUI backends can be used interactively 
from a python shell (see interactive) but TkAgg is the hands-down winner 
here since it can be use from any python shell whereas the GTK and Wx 
backends require a GUI specific shell
     * Pretty widgets: If you want to embed matplotlib in an application 
and pretty GUIs are important to you, Wx, GTK, GTKAgg or GTKCairo are 
probably your best best. Tk widgets are not visually stunning."

==========

My brain hurts! Actually, I've always just wanted to use TK (because it 
comes with Python), but I have never been able to figure out how to blit 
arbitrary bitmaps to a TK canvas (though last I tried was years ago).

By the way, also jumping from your links, I came across the Enthought 
"traits" package:
   http://code.enthought.com/traits/
which is something like what I added to PataPata for properties to wrap wx 
widgets. They came at it also from wrapping GUI widgets originally it 
looks like. But I'm not sure their framework is extensible to prototypes 
the way I want to use them. So, anyway, funny how some of these deeper 
language issues come up with looking at various graphics libraries. And it 
clearly shows that the "property" concept in Python could benefit from 
some more generalization. I added things like side-effects (and plan to 
add something I might term dependency paths); they added things like 
validation (a good point, as they said otherwise graphics errors tend to 
occur far in the code from where values are set). We both want to add 
Smalltalk-like "changed" or "notify" events. They have a nice general 
purpose solution, though it is class-oriented, not Prototype oriented. 
Hopefully Python3K might address improving properties? It seems to me that 
if one wants ot make graphcis easy to use, havign a consistent way to 
address graphical objects using soem form of properties might be very 
important. Certainly VB and Delphi have had great success wrapping 
arbitrary components with properties (and I think this might apply whether 
or not the user could interact with them).

Just a thought: rather than a new GUI implementation, improving the Python 
GUI FAQ with lots of this information and pros and cons and so on might be 
a very valuable effort just by itself. So much of choices depends on 
specifics and tiny details. For example, I'm fairly happy with wx, but 
there is this bug with dragging certain widgets under GTK 2.6. And of 
course, I also want platform independent fonts (and I'm not sure how to 
get those best, wx uses sizers to get platform independent dialog looks, 
but the sizes may still vary across platforms). Maybe this 2D, 3D, and 
Python GUI efforts needs a web site or blog or something? Some place where 
the nitty gritty details gets hashed out? Might be one already? Kind of 
like this one for programming languages?
     http://lambda-the-ultimate.org/
But specific to Python and graphics and user interaction?
   http://www.google.com/search?hl=en&q=python+graphics
Might be something to think about if it does not already exist.

--Paul Fernhout

Dethe Elza wrote:
> On 5/28/06, Paul D. Fernhout  wrote:
> 
>> If you haven't already, you could check out:
> 
> 
> Also:
> 
> PIL.ImageDraw
>    http://www.esrf.fr/computing/bliss/python2/pil/PIL.ImageDraw.html
>    http://www.pythonware.com/library/pil/handbook/imagedraw.htm
>    "The ImageDraw module provide simple 2D graphics for Image
> objects. You can use this module to create new images, annotate or
> retouch existing images, and to generate graphics on the fly for web
> use."
> 
> Aggdraw
>    http://effbot.org/zone/draw-agg.htm
>    "The aggdraw module implements the basic WCK 2D Drawing Interface
> on top of the AGG library. This library provides high-quality drawing,
> with anti-aliasing and alpha compositing, while being fully compatible
> with the WCK renderer."
> 
> Matplotlib
>    http://matplotlib.sourceforge.net/
>    "matplotlib is a python 2D plotting library which produces
> publication quality figures in a variety of hardcopy formats and
> interactive environments across platforms. matplotlib can be used in
> python scripts, the python and ipython shell (ala matlab or
> mathematica), web application servers, and six graphical user
> interface toolkits."
> 
> Kiva
>   http://code.enthought.com/kiva/
>   "Kiva is a multi-platform DisplayPDF drawing engine that supports
> multiple output backends, including Windows, GTK, and Macintosh native
> windowing systems, a variety of raster image formats, PDF, and
> Postscript."
> 
> DrawBot/NodeBox (OS X only, but useful as examples of simple 2D systems)
>    http://drawbot.com/index.html
>    http://nodebox.net/manual/reference/topics.php
>    "DrawBot is an powerful, free application for MacOSX that invites
> you to write simple Python scripts to generate two-dimensional
> graphics. The builtin graphics primitives support rectangles, ovals,
> (bezier) paths, polygons, text objects and transparency."
> 
> PyCairo
>    http://cairographics.org/pycairo
>    "Cairo is a library for drawing vector graphics. Vector graphics
> are interesting because when they appear on screen, they don't lose
> clarity when resized or transformed."
> 
> --Dethe
> 
> 

From pdfernhout at kurtz-fernhout.com  Tue May 30 20:43:24 2006
From: pdfernhout at kurtz-fernhout.com (Paul D. Fernhout)
Date: Tue, 30 May 2006 14:43:24 -0400
Subject: [Edu-sig] Elementary graphics library
In-Reply-To: <447C8C5D.2050506@kurtz-fernhout.com>
References: <10c99c2a0605280959n5481b536ue71f28153447a897@mail.gmail.com>		<447A0885.6060001@kurtz-fernhout.com>	<24d517dd0605281755k72986ee2ye0822b8993a77f41@mail.gmail.com>
	<447C8C5D.2050506@kurtz-fernhout.com>
Message-ID: <447C924C.4070204@kurtz-fernhout.com>

Paul D. Fernhout wrote:
> Just a thought: rather than a new GUI implementation, improving the Python 
> GUI FAQ with lots of this information and pros and cons and so on might be 
> a very valuable effort just by itself. So much of choices depends on 
> specifics and tiny details. For example, I'm fairly happy with wx, but 
> there is this bug with dragging certain widgets under GTK 2.6. And of 
> course, I also want platform independent fonts (and I'm not sure how to 
> get those best, wx uses sizers to get platform independent dialog looks, 
> but the sizes may still vary across platforms). Maybe this 2D, 3D, and 
> Python GUI efforts needs a web site or blog or something? Some place where 
> the nitty gritty details gets hashed out? Might be one already? Kind of 
> like this one for programming languages?
>      http://lambda-the-ultimate.org/
> But specific to Python and graphics and user interaction?
>    http://www.google.com/search?hl=en&q=python+graphics
> Might be something to think about if it does not already exist.

To answer part of my question, there was a Python GUI sig but it got 
retired in 1999. And I can't access the archives for some reason (when I 
wanted to see why):
   http://www.python.org/community/sigs/retired/gui-sig/
The link:
   http://mail.python.org/pipermail/gui-sig/
goes to:
"The requested URL /pipermail/gui-sig/ was not found on this server."

There is the ongoing Python Image Processign SIG
   http://www.python.org/community/sigs/current/image-sig/
though I had thought that was more oriented around the specific PIL package.

It seems to me that graphics are a powerful way to show people something 
in terms of education, as well as a powerful way for kids to learn about 
themselves through visualization, so having all these choices made neat 
and tidy on a web site (or log kept up to date) for beginners or educators 
who want to make software seems like a good thing. Presumably the demise 
of Gui-sig suggests it is hard to keep up that sustained level of 
interest? But I know I see questions on this on the Python mailing list 
(i.e. what GUI should I use) all the time. Before this question was asked 
here, I had never really thought about how many options for Python and 
graphics and GUIs there really are -- dozens it seems. So, clearly any 
sort of effort put in this direction (including the original poster's plan 
to make simple wrapper) is going to be in the right direction.

--Paul Fernhout

From delza at livingcode.org  Tue May 30 20:53:38 2006
From: delza at livingcode.org (Dethe Elza)
Date: Tue, 30 May 2006 11:53:38 -0700
Subject: [Edu-sig] Elementary graphics library
In-Reply-To: <447C8C5D.2050506@kurtz-fernhout.com>
References: <10c99c2a0605280959n5481b536ue71f28153447a897@mail.gmail.com>
	<447A0885.6060001@kurtz-fernhout.com>
	<24d517dd0605281755k72986ee2ye0822b8993a77f41@mail.gmail.com>
	<447C8C5D.2050506@kurtz-fernhout.com>
Message-ID: <24d517dd0605301153j4fda7dd7s34e64449fe3496e1@mail.gmail.com>

"The full set of Ginsu 2D interfaces for only $9.95 a month?  But
wait, there's more..."

Mirra
http://www.ixi-software.net/content/body_software_mirra.html
"Mirra is a 2D openGL python library. It defines a set of classes to
render primitive shapes (Text, Pixel, Line, Circle, Rect, Bitmap,
BitmaPolygon) and manages rendering and user input (mouse and
keyboard). Mirra focuses on interaction and implements an event
listener and classes that receive mouse events. (in a way like
macromedia director or flash do).
It runs using pygame(SDL) but it can also be used under wxPython.
Mirra is also thought to teach students (basically design and
multimedia students) programming in python by playing around with
graphics."

SVGDraw
http://www2.sfk.nl/svg
Create SVG (XML for 2D) images using Python.

> My head is spinning. :-)

Just wait till we delve into 3D %-)

> Just a thought: rather than a new GUI implementation, improving the Python
> GUI FAQ with lots of this information and pros and cons and so on might be
> a very valuable effort just by itself.

I think this is an excellent idea.

> So much of choices depends on
> specifics and tiny details. For example, I'm fairly happy with wx, but
> there is this bug with dragging certain widgets under GTK 2.6.

I haven't used wx for some time, but when I did it a) sucked on OS X,
and b) seemed to be a random mix of reasonably polished widgets and
half-baked crap that would be as useful as writing your resume in
crayon.  It also suffers from being huge and very Windows-focused. I
can understand using it on Windows (beats using MFC, but so does
hitting yourself with a ball-peen hammer), but I think it goes
downhill as you move to Linux and drops off the cliff when you go to
OS X.  Just my impression, though I've seen the same feelings
expressed elsewhere.  I'd sooner use PyGame, and PyGame sucks for
general UI/event handling (by itself, there are libraries on top of
PyGame which help).

Of all the systems, I think PyCairo has the most momentum (and also
has OpenGL hardware acceleration). Mozilla and GTK are both moving to
Cairo, so it's getting lots of real-world use, profiling, bug-fixing,
and speed-ups. This makes it a bit of a moving target, but the APIs
should be fairly stable even though the implementation is in flux.

Caveat emptor. I haven't spent a lot of time with any of these (on the
Mac I can access Quartz from Python, which works for me).  I'm
planning to explore further for an article or blog at some point, but
any recommendations I make at this point have to be taken with a huge
grain of salt.

And of
> course, I also want platform independent fonts (and I'm not sure how to
> get those best, wx uses sizers to get platform independent dialog looks,
> but the sizes may still vary across platforms). Maybe this 2D, 3D, and
> Python GUI efforts needs a web site or blog or something? Some place where
> the nitty gritty details gets hashed out? Might be one already? Kind of
> like this one for programming languages?
>      http://lambda-the-ultimate.org/

Maybe just the Python Wiki?
http://wiki.python.org/moin/

> But specific to Python and graphics and user interaction?
>    http://www.google.com/search?hl=en&q=python+graphics
> Might be something to think about if it does not already exist.
>
> --Paul Fernhout

--Dethe

From francois.schnell at gmail.com  Tue May 30 23:59:32 2006
From: francois.schnell at gmail.com (francois schnell)
Date: Tue, 30 May 2006 23:59:32 +0200
Subject: [Edu-sig] Accessibility to non CS types?
In-Reply-To: <447BFEC7.8050605@kurtz-fernhout.com>
References: 
	<44775EFB.6070606@kurtz-fernhout.com>
	<13a83ca10605281500h67954015w85cd3f3b4cbca2f1@mail.gmail.com>
	<447B30F2.60806@kurtz-fernhout.com>
	<13a83ca10605291548k2619608bx5a4a42a5a1922c32@mail.gmail.com>
	<447BFEC7.8050605@kurtz-fernhout.com>
Message-ID: <13a83ca10605301459y2ed43fcaw54068fd15c9a395a@mail.gmail.com>

On 30/05/06, Paul D. Fernhout  wrote:
>
>
> and later making documentation especially when the system settles down a
> bit (including perhaps a movie of yours for SourceForge? Or even a main
> page?).


I would be pleased to help with that, maybe one or two neat "5 minutes
programs" and also a collection of short "how-to".

For now I've added quick "raw/draft" recording of :

How to add a method to a morph:
http://francois.schnell.free.fr/bazar/patapata-add-method/patapata-add-method.html

How-to send an order from one morph to another one:
http://francois.schnell.free.fr/bazar/pata-send-order/pata-pata-send-order.html

Concerning the licences your choice seems fine to me and I also think that a
wiki section helping to find our way in the 2D/3D jungle of Python would be
a breeze :)
( I'll propably give a look at cairo and mirra later ).

francois


As for promotion, I don't want too many users just yet with the
> system in its early stages and still subject to major changes before it
> settles down (why I have not announced it to the general Python list), but
> in the long term that would be great. What a young project needs most is a
> handful of very interested people such as yourself, so low key recruiting
> like that even now would be wonderful. Also, if after using it a bit you
> decide to make a roughly prioritized list of desirable minor changes, that
> would help too.
>
> Here is a new release as a zip file with a few files in it.
>
> http://sourceforge.net/project/showfiles.php?group_id=165910&package_id=188385&release_id=420989
> Or:
>
> http://svn.sourceforge.net/viewcvs.cgi/patapata/trunk/releases/PataPata_v101.zip?view=log
> This is mainly to fix some bugs I introduced when adding properties and wx
> widget support which prevented properly loading and saving world defining
> Python files. Files should now save and load correctly again (I noticed
> you did not show that in your movie :-). A big change from before is that
> I finally split up the single file into three files -- one for the GUI,
> one for the Example World and one for the Prototype library classes (which
> is why it is now in a zip file which expands to a directory). I also
> changed how the world file is loaded, from an eval to an import statement
> (which means the world files need to be in your Python path I think, or
> the local directory).
>
> I also added a license.txt file clearly stating the current work is under
> the GPL (meaning applications written with it would also be under the
> GPL). Still, my intent down the road is that if there is any small pieces
> of core technology in PataPata that would make sense to be in the core
> Python distribution (like improvements to Python or Jython so they
> supported prototypes in a better way, or perhaps support related to hooks
> for networked debugging and such), those parts would (if all relevant
> contributors agree) be dual licensed under the latest Python license as
> well as the GPL. However, I think a lot of the system will end up GPL,
> including all the self-drawn widgets. I know the GPL precludes adoption by
> certain developers and uses, but I think it also is desirable by certain
> others including because it solves certain coordination issues as a sort
> of project constitution. Looking at the licenses you or Ian or some others
> posting here (e.g. Art's PyGeo) have chosen I think GPL should work out
> well enough for making a free educational platform (especially given that
> the more general programming skills kids learn with it are usable on any
> Python application). Also, it allows me to draw from GPL-d code such as
> from some GPL's parts of GNU Smalltalk or the GPL'd Pyxel (widgets in
> Python) which might help speed development of some parts and otherwise
> would be precluded if I did not go with the GPL.
>
> A next goal is then to get some more widgets working (buttons, edit
> fields, bitmaps) and support basic HyperCard-like functionality, and do a
> simple card stack (possibly Bucky Fuller, but could be other topics; if
> you have a specific simulation idea or topic area you would like to see, I
> could make some widgets to support that). Important to this is supporting
> a system of nested views of some widgets inside another (or even nested
> worlds). Someday, perhaps even converting a lot of the examples from
> PythonCard might be a goal, so it makes sense early on to draw from
> PythonCard as much as possible, especially some of their naming
> conventions.
>
> Using properties, the system can now wrap wxWidgets (or perhaps TK, not
> that I have tried that), and while that is useful, right now I just don't
> think I want to focus on that. Or to look at it from another point of
> view, what's the point of making a RAD (Rapid Application Development)
> system if I am just going to use it to wrap wxPython wrappers for
> wxWidgets (which is tedious)?  Building widgets its itself a good test of
> what the system can do and motivates further work on it. And if I develop
> new widgets using a few primitive operations based around BitBlit (or
> other simple drawing) like Squeak does it (drawing on whatever I can find
> on the web that uses Python) then I can probably also get them running
> under Jython without too much trouble, which means they could run as a
> Java applet. [Although something like Cairo might not be accessible to an
> Applet?] Basically, that is a Squeak-like approach, sending in mouse and
> key events into a world of custom Morphs. So I plan to pull out the
> wrapped wxButton and go to pure Morphs pretty soon. Still, it was worth it
> to actually wrap a few wxWidgets because that caused the improvements in
> the property system. Should doing the basic widgets prove too difficult,
> then I can fall back on wrapping wxWidgets or TK widgets or even GTK
> widgets etc.
>
> If you know of any GPL compatible sources of widget sets in Python to draw
> from, that could really help a lot in terms of minimizing wheel
> reinvention (Dethe just posted some which I need to look at). Right now
> I'm thinking of PythonCard for the event naming structure, and maybe Pyxel
> and OcempGUI and GNU Smalltalk for some implementation ideas. The GUI uses
> wx right now, but I've been musing over using Cairo or something like it
> instead -- but it would be best if whatever is used can work both in
> Python and in a Jython Applet (either as a simple layer written for
> PataPata that works on both, or as one library like Cairo that might work
> in both). For now, my default is to just do some basic drawing with wx and
> then port it to Jython/Swing at some point.
>
> I also have a few more things I want to add to properties from Smalltalk,
> mostly automatically tracking dependencies and sending changed messages,
> but more on that if/when I get to that.
>
> You wrote: "make PataPata a good imagination amplifier !" That sounds like
> a good concept to always keep in mind as it develops.
>
> All the best.
>
> --Paul Fernhout
> By the way, I was the one mentioning Ocaml :-) though I mainly see it as a
> "much better C" than something I want to be coding in all of the time. I
> prefer Smalltalk-like and Self-like systems with dynamic objects,
> including Python, but that's because, except for coding the VM or certain
> libraries, I am more interested in changing the system while it runs (like
> Smalltalk & Python can) than having the fastest system (like OCaml & C
> can). Naturally, for other people working on other problems (especially
> numerically oriented-ones), their priorities may differ.
>
> francois schnell wrote:
> > On 29/05/06, Paul D. Fernhout  wrote:
> >
> >>
> >> Francois-
> >>
> >> Wow!  Thanks for making that Flash recording:
> >>
> >>
> http://francois.schnell.free.fr/bazar/patapata-test1/patapata-test1.html
> >> That is a neat demo showing things I had not even thought of, like with
> >> the jumping Morphs (and far beyond my presentation skills).
> >
> >
> >
> > Well what I''m doing here is not really a "neat" presentation it's just
> > that
> > when I find something interesting like this I like to show it to other
> > people :)  (I'm also very much into Free Culture and Free Software
> > advocating).
> >
> > My wife is now
> >
> >> finally impressed somewhat with what I am doing. :-) The version you
> are
> >> using did benefit from her trying an earlier version and her feedback
> on
> >> it, as several things she (also a programmer) tried that were hard or
> >> confusing or generated errors, I made easier or fixed.
> >
> >
> >
> > Oh , send also to her "mes homages" and congratulations from the french
> man
> > :) (my English spouse still have nearly no idea what I'm doing with
> > electronics bits and computers all over the place).
> >
> >
> >> To answer your first question: To add a method, try right-clicking in
> the
> >> yellow inspector pane [...]
> >>
> >
> > Dear me ... I didn't think you already have that and didn't try ... it
> > works
> > great thanks ! fun times ahead :)
> >
> > To answer your second question: To execute a method in another morph,
> you
> >
> >> must first have a pointer to that morph directly. Ideally, that would
> be
> >> supported by cut and paste in the inspector, but you can't do that yet.
> >> However, you can, say, go to Morph 0 and add a field and call it
> "morph1"
> >> and then when asked for the value, enter (without quotes):
> >> "world.morphs[1]" which will evaluate to Morph 1 in the world. Then you
> >> could reference "self.morph1" in any method of Morph 0, like to call
> >> "self,morph1.X()" directly.[...]
> >
> >
> >
> > Great my objects can now talk to each others ! It will be awesome when
> > you'll also have "quick integration" of this. :) More fun times ahead
> :))
> >
> >
> >> I'm guessing you're using WinXP? Nice to see the wxWindows button
> >> dragging
> >> properly.
> >
> >
> >
> > I'm mainly using  XP for software  I don't  have  on my  Ubuntu Dapper
> > (like quick sreencasting, itunes/podcasts for my ipod, etc). I have one
> > screen/keyboard/mouse and a switch quickly between the Linux and XP box.
> >
> > So many times one does things and thinks no one notices or cares, so I'm
> >
> >> very excited to see someone trying it (and going to the effort to make
> a
> >> Flash video, too). Thanks again for trying it and the encouragement.
> >
> >
> >
> > Well ... maybe it's why Einstein said it's difficult for people to
> > understand what they never experienced (ie in our case a visual hands-on
> > squeak-like familiarity of objects land) , that's also why he said that
> > imagination is more important than knowledge. I believe it's Alan Kay
> who
> > said that the computer revolution haven't started yet in education and
> that
> > kids ~need "imagination amplifiers" => make PataPata a good imagination
> > amplifier !
> >
> >
> >> As
> >> regards future evolution, right now I'm at a decision point as to
> whether
> >> to push forward in Python further or, as per my previous discussions
> here
> >> with Kirby where he rightly points to dominant paradigms in specific
> >> languages, to jump to something like OCaml and use it to build a
> >> Self-like
> >> prototype language on top of it (something like io, which looks great,
> >>    http://www.iolanguage.com/about/
> >> but with a Smalltalk/Self-derived keyword syntax, which I feel is
> >> desirable), and so essentially producing a system that supports two
> >> extremes of permissiveness at two different levels -- strong (but
> >> implicit) typing at a speedy supporting layer and anything-goes
> >> prototypes
> >> above that for most GUI development work. On the other hand, I am
> >> making a
> >> lot of progress with Python (and not knowing OCaml much) and a Python
> >> version has value to me for other reasons. So, this seems like a big
> vote
> >> on keeping it all in Python for now?
> >
> >
> >
> > Well I don't know OCaml and io but If I were you I would be suspicious
> of a
> > "yankee" advising you a language written by french people ;)
> >
> > I personally would *love* if you continue this in Python, I'm not
> > anymore in
> > a testing phase, I've seen enough to "adopt" it and see how I can use it
> > for
> > games/simulations/teaching and help where I can :)
> >
> > I probably won't be able to help on the core "PataPata"  but my Python
> > skills gets better and better (I'm quite new to Python).
> >
> > I can help with :
> > - bug tracking
> > - playing with it and doing short examples/demos (games/simulations)
> > - promoting and doc (especially in the French Python sphere)
> > - i18n and French translation
> > - I begin to know more and more the multimedia part of Python (sound,
> > video,
> > streaming), could be handy one day
> > - extend morphs to the analog world (data acquisition and automation)
> > - I'm good at testing plenty of things and finding gems (useful if you
> > don't
> > want  to reinvent the wheel). :)
> >
> > Well it's bed time on this part of the globe =>  $ python dreamland.py
> >
> > Please keep up your excellent work  and use Python :)
> > 
> >
> > francois
> >
> > All the best.
> >
> >>
> >> --Paul Fernhout
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20060530/726766f8/attachment.htm 

From andre.roberge at gmail.com  Wed May 31 00:32:03 2006
From: andre.roberge at gmail.com (Andre Roberge)
Date: Tue, 30 May 2006 19:32:03 -0300
Subject: [Edu-sig] Accessibility to non CS types?
In-Reply-To: <447B30F2.60806@kurtz-fernhout.com>
References: 
	<44775EFB.6070606@kurtz-fernhout.com>
	<13a83ca10605281500h67954015w85cd3f3b4cbca2f1@mail.gmail.com>
	<447B30F2.60806@kurtz-fernhout.com>
Message-ID: <7528bcdd0605301532g2d715a24ve2c3845ad764c9a@mail.gmail.com>

On 5/29/06, Paul D. Fernhout  wrote:
>
> Francois-
>
> Wow!  Thanks for making that Flash recording:
>
> http://francois.schnell.free.fr/bazar/patapata-test1/patapata-test1.html
> That is a neat demo showing things I had not even thought of, like with
> the jumping Morphs (and far beyond my presentation skills).


[snip]

Now that you made a video, perhaps that spark of enlightenment will
> spread. :-)
>
> Indeed!  This is really neat.  I had downloaded a much earlier version
which left me rather underwhelmed (probably because I had no clue as to what
patapata was leading to).  This is really neat.  Congrats Paul!

Andr?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20060530/0e57038c/attachment.html 

From kirby.urner at gmail.com  Wed May 31 01:20:17 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Tue, 30 May 2006 16:20:17 -0700
Subject: [Edu-sig] Accessibility to non CS types?
In-Reply-To: <7528bcdd0605301532g2d715a24ve2c3845ad764c9a@mail.gmail.com>
References: 
	<44775EFB.6070606@kurtz-fernhout.com>
	<13a83ca10605281500h67954015w85cd3f3b4cbca2f1@mail.gmail.com>
	<447B30F2.60806@kurtz-fernhout.com>
	<7528bcdd0605301532g2d715a24ve2c3845ad764c9a@mail.gmail.com>
Message-ID: 

On 5/30/06, Andre Roberge  wrote:

> Indeed!  This is really neat.  I had downloaded a much earlier version which
> left me rather underwhelmed (probably because I had no clue as to what
> patapata was leading to).  This is really neat.  Congrats Paul!
>
> Andr?

If wanted to see similar narrated movies of rur-ple in action as well.
 Now that I see PP in that format, I'm even more eager to see us build
the Python apps preview library.

Kirby

From andre.roberge at gmail.com  Wed May 31 01:23:21 2006
From: andre.roberge at gmail.com (Andre Roberge)
Date: Tue, 30 May 2006 20:23:21 -0300
Subject: [Edu-sig] Accessibility to non CS types?
In-Reply-To: 
References: 
	<44775EFB.6070606@kurtz-fernhout.com>
	<13a83ca10605281500h67954015w85cd3f3b4cbca2f1@mail.gmail.com>
	<447B30F2.60806@kurtz-fernhout.com>
	<7528bcdd0605301532g2d715a24ve2c3845ad764c9a@mail.gmail.com>
	
Message-ID: <7528bcdd0605301623y4d473518x353c383e98ced0f9@mail.gmail.com>

On 5/30/06, kirby urner  wrote:
>
> On 5/30/06, Andre Roberge  wrote:
>
> > Indeed!  This is really neat.  I had downloaded a much earlier version
> which
> > left me rather underwhelmed (probably because I had no clue as to what
> > patapata was leading to).  This is really neat.  Congrats Paul!
> >
> > Andr?
>
> If wanted to see similar narrated movies of rur-ple in action as well.
> Now that I see PP in that format, I'm even more eager to see us build
> the Python apps preview library.


I have been planning to do this for a while and, in fact, have been
contacted by the folks behind "showmedo" to do just that and post it on
their website.  I'll try to do one soon and will advertise on this list.

Andr?


Kirby
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20060530/fa5106cb/attachment.html 

From dblank at brynmawr.edu  Wed May 31 02:48:23 2006
From: dblank at brynmawr.edu (dblank at brynmawr.edu)
Date: Tue, 30 May 2006 20:48:23 -0400 (EDT)
Subject: [Edu-sig] Accessibility to non CS types?
In-Reply-To: <7528bcdd0605301532g2d715a24ve2c3845ad764c9a@mail.gmail.com>
References: 
	<44775EFB.6070606@kurtz-fernhout.com>
	<13a83ca10605281500h67954015w85cd3f3b4cbca2f1@mail.gmail.com>
	<447B30F2.60806@kurtz-fernhout.com>
	<7528bcdd0605301532g2d715a24ve2c3845ad764c9a@mail.gmail.com>
Message-ID: <51463.68.34.179.248.1149036503.squirrel@webmail.brynmawr.edu>

Very nice demonstration; nice way to make it clear what PataPata is about!
(The first thing I was wondering about was if there was a way to make a
dynamic change apply to all current objects? Say, change all of their
colors, or methods.)

Also, you can make your videos using your favorite tool, Python! I've made
a couple of videos of our Python-based robotics system, including a pure
Python 2-D simulator, complete with sonar, infrared, bumpers, and
simulated vision. I've also listed instructions on how to make the videos
here with Python and VNC thanks to pyvnc2swf:

http://pyrorobotics.org/video/

Not quite as smooth as some other methods, but not too bad so far.

-Doug

> On 5/29/06, Paul D. Fernhout  wrote:
>>
>> Francois-
>>
>> Wow!  Thanks for making that Flash recording:
>>
>> http://francois.schnell.free.fr/bazar/patapata-test1/patapata-test1.html
>> That is a neat demo showing things I had not even thought of, like with
>> the jumping Morphs (and far beyond my presentation skills).
>
>
> [snip]
>
> Now that you made a video, perhaps that spark of enlightenment will
>> spread. :-)
>>
>> Indeed!  This is really neat.  I had downloaded a much earlier version
> which left me rather underwhelmed (probably because I had no clue as to
> what
> patapata was leading to).  This is really neat.  Congrats Paul!
>
> Andr?
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>



From kirby.urner at gmail.com  Wed May 31 19:12:45 2006
From: kirby.urner at gmail.com (kirby urner)
Date: Wed, 31 May 2006 10:12:45 -0700
Subject: [Edu-sig] Summary of Gnu Math project
Message-ID: 

Here's a pithy summary of the Gnu Math project, with an eye towards
contextualizing my Pythonic Mathematics as one approach among several.

http://mathforum.org/kb/thread.jspa?threadID=1390937

Kirby

From francois.schnell at gmail.com  Wed May 31 23:56:51 2006
From: francois.schnell at gmail.com (francois schnell)
Date: Wed, 31 May 2006 23:56:51 +0200
Subject: [Edu-sig] Accessibility to non CS types?
In-Reply-To: <51463.68.34.179.248.1149036503.squirrel@webmail.brynmawr.edu>
References: 
	<44775EFB.6070606@kurtz-fernhout.com>
	<13a83ca10605281500h67954015w85cd3f3b4cbca2f1@mail.gmail.com>
	<447B30F2.60806@kurtz-fernhout.com>
	<7528bcdd0605301532g2d715a24ve2c3845ad764c9a@mail.gmail.com>
	<51463.68.34.179.248.1149036503.squirrel@webmail.brynmawr.edu>
Message-ID: <13a83ca10605311456y6ba42e65ie72afbc70c217772@mail.gmail.com>

On 31/05/06, dblank at brynmawr.edu  wrote:
>
> Very nice demonstration; nice way to make it clear what PataPata is about!


Thanks Doug I begin to gather all this on a single page (while testing
googlepages in the same shot...):
http://francois.schnell.googlepages.com/patapata

(The first thing I was wondering about was if there was a way to make a
> dynamic change apply to all current objects? Say, change all of their
> colors, or methods.)


This would be interesting, especially for emergent systems simulations I
imagine :)
http://serendip.brynmawr.edu/complexity/course/emergence06/

I find this to be a fascinating subject. I've read Steven Johnson book
(emergence) two years ago and "Out of Control" (Kelly) is waiting its turn
on my "to read" pile of books.

Also, you can make your videos using your favorite tool, Python! I've made
> a couple of videos of our Python-based robotics system, including a pure
> Python 2-D simulator, complete with sonar, infrared, bumpers, and
> simulated vision. I've also listed instructions on how to make the videos
> here with Python and VNC thanks to pyvnc2swf:
>
> http://pyrorobotics.org/video/
>
> Not quite as smooth as some other methods, but not too bad so far.


Great and neat screencasts.  I haven't seen the audio integration before
with vnc2swf, I will try it, thanks. Pyrobotics seems also a very
interesting project  :)  (I'm also interested in the electronic/Python field
: http://www.liberlab.net/ )

francois


-Doug
>
> > On 5/29/06, Paul D. Fernhout  wrote:
> >>
> >> Francois-
> >>
> >> Wow!  Thanks for making that Flash recording:
> >>
> >>
> http://francois.schnell.free.fr/bazar/patapata-test1/patapata-test1.html
> >> That is a neat demo showing things I had not even thought of, like with
> >> the jumping Morphs (and far beyond my presentation skills).
> >
> >
> > [snip]
> >
> > Now that you made a video, perhaps that spark of enlightenment will
> >> spread. :-)
> >>
> >> Indeed!  This is really neat.  I had downloaded a much earlier version
> > which left me rather underwhelmed (probably because I had no clue as to
> > what
> > patapata was leading to).  This is really neat.  Congrats Paul!
> >
> > Andr?
> > _______________________________________________
> > Edu-sig mailing list
> > Edu-sig at python.org
> > http://mail.python.org/mailman/listinfo/edu-sig
> >
>
>
> _______________________________________________
> Edu-sig mailing list
> Edu-sig at python.org
> http://mail.python.org/mailman/listinfo/edu-sig
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/edu-sig/attachments/20060531/2c0f4e29/attachment.htm