Deprecating reload() ???

[Hung Jung Lu]

> >> On Fri, 12 Mar 2004 08:45:24 -0500, Peter Hansen <peter at engcorp.com>
> >> wrote:
> >> 
> >> It's worse than just a surprise.  It's a serious problem when what you
> >> need to do is what most people are expecting -- replace every
> >> reference to objects in the old module with references to the new
> >> objects.  The problem becomes a near impossibility when those
> >> references are scattered throughout a multi-module program.

You could use a class instead of a module. I have done that kind of
thing with classes and weakrefs. By the way, it kind of surprises me
that no one has mentioned weakref in this thread. It's not too hard to
keep a list of weakrefs, and everytime an object is created, you
register it with that list. Now, when the new class comes in (e.g. via
reload(),) you get the list of weakrefs of the existing objects, and
re-assign their __class__, and voila, dynamic change of class
behavior. Of course, if you spend some time and push this feature into
the metaclass, everytime becomes even easier.

But it is true that in Python you have to implement dynamic refreshing
of behavior (module or class) explicitly, whereas in Ruby, as I
understand, class behavior refreshing is automatic.

David MacQuigg <dmq at gain.com> wrote in message news:<ba1450tvgdttth3ddu88qjevsv9k5b1tpb at 4ax.com>...
>
> I agree, most programs should not have 'reload()' designed in, and
> those that do, should be well aware of its limitations.  I'm concerned
> more about interactive use, specifically of programs which cannot be
> conveniently restarted from the beginning.  I guess I'm spoiled by HP
> BASIC, where you can change the program statements while the program
> is running! (half wink)

Edit-and-continue. Which is kind of important. For instance, I often
have to load in tons of data from the database, do some initial
processing, and then do the actual calculations. Or in game
programming, where you have to load up a lot of things, play quite a
few initial steps, before you arrive at the point of your interest.
Now, in these kinds of programs, where the initial state preparation
takes a long time, you really would like some "edit-and-continue"
feature while developing the program.

For GUI programs, edit-and-continue is also very helpful during
development.

And for Web applications, actually most CGI-like programs (EJB in Java
jargon, or external methods in Zope) are all reloadable while the
web/app server is running. Very often you can do open-heart surgery on
web/app servers, while the website is running live.

> Here is a use-case for classes. I've got hundreds of variables in a
> huge hierarchy of "statefiles".  In my program, that hierarchy is
> handled as a hierarchy of classes.  If I want to access a particular
> variable, I say something like:
> wavescan.window1.plot2.xaxis.label.font.size = 12
> These classes have no methods, just names and values and other
> classes.

"State file" reminds me of a programming paradigm based on REQUEST and
RESPONSE. (Sometimes REQUEST alone.) Basically, your program's
information is stored in a single "workspace" object. The advantage of
this approach is: (1) All function/method calls at higher level have
unique "header", something like f(REQUEST, RESPONSE), or f(REQUEST),
and you will never need to worry about header changes. (2) The REQUEST
and/or RESPONSE object could be serialized and stored on disk, or
passed via remote calls to other computers. Since they can be
serialized, you can also intercept/modify the content and do unit
testing. This is very important in programs that take long time to
build up initial states. Basically, once you are able to serialize and
cache the state on disk (and even modify the states offline), then you
can unit test various parts of your program WITHOUT having to start
from scratch. Some people use XML for serialization to make state
modification even easier, but any other serialization format is just
as fine. This approach is also good when you want/need some
parallel/distributed computing down the future, since the serialized
states could be potentially be dispatched independently.

Today's file access time is so fast that disk operations are often
being sub-utilized. In heavy numerical crunching, having a "workspace"
serialization can make development and debugging a lot less painful.

> If I reload a module that changes some of those variables, I would
> like to not have to hunt down every reference in the running program
> and change it manually.

In Python the appropriate tool is weakref. Per each class that
matters, keep a weakref list of the instances. This way you can
automate the refresing. I've done that before.

regards,

Hung Jung