[Edu-sig] FYI: PataPata postmortem link

[Ian Bicking]

David Boddie wrote:
>> There's some similar issues being considered for OLPC.  Specifically the
>> laptop has a "view source" key, which (unsurprisingly) lets you view the
>> source of what you are doing.  What that means is application (aka
>> "Activity") specific, but a general Python solution is called for.
>>
>> Of course it's a little hard to say what that actually should be.  Just
>> a text editor?  Not too exciting.  Really there should be a view of the
>> process.  And some way to manipulate the in-process objects and source.
> 
> When I hear something like this, I think of pipelines or trees of
> self-contained components rather than source-level objects. Wasn't
> there a talk at EuroPython 2006 about data processing that covered
> this approach?

There's certainly tree-like structures in memory (and pipeline, and 
cubbies, and all sorts of other data structures).  And it's entirely 
reasonable to create a browser for these objects, where you can inspect 
and traverse those in-memory objects.

Where that currently falls down is that while you can change those 
objects, that change is not generally persistent.  When the process is 
restarted, it will restart just like it was before.

Given a more constrained concept of object that included a persistence 
system, you could make that object manipulation meaningful.  But then 
you need a persistence system -- which notably Squeak has, and that's an 
idea most fully explored in Python in Zope 2 (with through-the-web 
development).  Including a persistence system introduces a lot of 
complications, because key parts of the application have been moved into 
your persistence system and out of your source code.  I'd like to avoid 
this (I wasn't a very happy Zope 2 through the web developer).

In particular cases it might be more reasonable.  For instance, consider 
glade (http://glade.gnome.org/) -- it's an XML description of a GUI. 
For an application that uses Glade and given an editor specific to that, 
you could edit the "objects" and then the XML is automatically written 
out.  You'd be doing simultaneous editing of the in-process objects and 
the "source code", in this case the XML description of the layout.

Glade isn't magic, of course -- you could add automatic serialization to 
any kind of object, or recreate something like Glade in Python.  For a 
small number of basic Python objects this is already possible; mostly 
functions.  Modules and classes are not nearly so simple.

But really if we can cover a set of compelling things that children 
would want to edit, an incomplete in-process editing system could be 
valuable.

> [...]
> 
>> Of course, at some point you need complete power, which means editing 
>> the source in ways that can only be meaningful when you restart the 
>> process from scratch.  I'm not sure how or where to make that break. 
>> OTOH, emphasizing clean/fast/easy restarts might be more general and 
>> easier to implement than in-process persistent editing.
> 
> In many ways, it's more interesting to consider making modified copies of
> existing processes. It avoids difficult issues with in-process interaction
> and encourages something like a prototype-based approach. It seems to me
> that this might work well with simple components, but maybe I'm just
> trying to avoid facing those difficult issues. :-/

Forking would clone a process.  But this doesn't get around the reload 
problem.  I could go into the details, but there's lots of tricky 
aspects to reloading a module in Python.  The reload() function is 
totally stupid -- it's just equivalent to:

   def reload(mod):
       exec open(mod.__file__).read() in mod.__dict__

As a result there's lots of references to the old objects.  For every 
class there is now two instances of the class.  Any imports like "from 
mod import Foo" will still be pointing at the old Foo.  There might be 
references to functions, bound methods, etc, and old instances with a 
__class__ pointing to the old definition.

People have implemented fancier reloaders that do better.  For instance, 
recursively replacing the __dict__ of classes, instead of just creating 
a new class.  There are always cases in which these fail.

That said, if we could identify those cases and give warnings we'd be 
getting a lot further.  Current reloaders are optimistic and ignore 
detectable problems.  Once the warnings are in, and given alternate 
methods (e.g., alternatives to mutable class-level variables), we would 
be encouraging people to write reloadable code.


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