[Edu-sig] FYI: PataPata postmortem link

[Ian Bicking]

Paul D. Fernhout wrote:
> Just as an FYI, as a way to wind up the PataPata project (or at least one 
> phase of it), I wrote a lengthy postmortem critique of the PataPata 
> project to date, plus ideas for where to go from here. You can read the 
> critique by following this link:
> 
> "PataPata critique: the good, the bad, the ugly"
> http://sourceforge.net/mailarchive/forum.php?thread_id=31111569&forum_id=48729
> 
> Comments welcome.

Thanks for putting this together; it's useful to know how this went, as 
it was a fairly ambitious rethinking of Python development.

There's some similar issues being considered for OLPC.  Specifically the 
laptop has a "view source" key, which (unsurprisingly) lets you view the 
source of what you are doing.  What that means is application (aka 
"Activity") specific, but a general Python solution is called for.

Of course it's a little hard to say what that actually should be.  Just 
a text editor?  Not too exciting.  Really there should be a view of the 
process.  And some way to manipulate the in-process objects and source. 
  One thing I was unsure of -- and I think your postmortem confirmed -- 
is whether it's really feasible to generally edit objects in-process in 
a persistent way.  I'm inclined not to go so far, perhaps simply relying 
on UI hints to indicate when the change is likely to be persistent. 
It's fairly easy to edit a function definition persistently, for 
instance, or add a function definition.  You can still explore and poke 
around in the process any way you want, but you don't have complete power.

Of course, at some point you need complete power, which means editing 
the source in ways that can only be meaningful when you restart the 
process from scratch.  I'm not sure how or where to make that break. 
OTOH, emphasizing clean/fast/easy restarts might be more general and 
easier to implement than in-process persistent editing.

I'm also not sure what to build on, or what to use.  It's interesting 
that you felt out-of-process interaction was successful.  This fits with 
my own intuition that in-process stuff can be dangerous and fragile. 
But I'm not that familiar with the details of how the interprocess 
communication should happen; perhaps IDLE is a good place to start 
looking.  Perhaps IDLE is a good place to start the development?  I 
don't believe Tk will be available on the laptops, only GTK, and 
probably not wx either, so that limits the possibility of reusing most 
UI, though other bits of code might be fine.

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