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