Deprecating reload() ???

[David MacQuigg]

On Sun, 14 Mar 2004 02:51:13 -0500, "Terry Reedy" <tjreedy at udel.edu>
wrote:

>
>"David MacQuigg" <dmq at gain.com> wrote in message
>news:6kk6501shlve52ds2rjdopa73jhpchprg3 at 4ax.com...
>> Just to make sure I understand this, I think what you are saying is
>> that if I have a module M1 that defines a value x = 3.1, it will be
>> impossible to keep track of the number of references to M1.x because
>> the object '3.1' may have other references to it from other modules
>> which use the same constant 3.1.  This really does make it impossible
>> to do a complete reload.
>
>Currently, this is possible but not actual for floats, but it is actual, in
>CPython, for some ints and strings.  For a fresh 2.2.1 interpreter
>
>>>> sys.getrefcount(0)
>52
>>>> sys.getrefcount(1)
>50
>>>> sys.getrefcount('a')
>7

I'm amazed how many of these shared references there are.

[snip]
>
>However, there is still the problem of instances and their __class__
>attribute.  One could, I believe (without trying it) give each class in a
>module an __instances__ list that is updated by each call to __init__.
>Then super_reload() could grab the instances lists, do a normal reload, and
>then update the __instances__ attributes of the reloaded classes and the
>__class__ attributes of the instances on the lists.  In other words,
>manually rebind instances to new classes and vice versa.

We need to draw a clean line between what gets updated and what
doesn't.  I would not update instances, because in general, that will
be impossible.  Here is a section from my update on Reload Basics at
http://ece.arizona.edu/~edatools/Python/Reload.htm  I need to provide
my students with a clear explanation, hopefully with sensible
motivation, for what gets updated and what does not.  Comments are
welcome.

Background on Reload
Users often ask why doesn't reload just "do what we expect" and update
everything.  The fundamental problem is that the current state of
objects in a running program can be dependent on the conditions which
existed when the object was created, and those conditions may have
changed.  Say you have in your reloaded module:

class C1:
    def __init__(self, x, y ):
      ...

Say you have an object x1 created from an earlier version of class C1.
The current state of x1 depends on the values of x and y at the time
x1 was created.  Asking reload to "do what we expect" in this case, is
asking to put the object x1 into the state it would be now, had we
made the changes in C1 earlier.

If you are designing a multi-module program, *and* users may need to
reload certain modules, *and* re-starting everything may be
impractical, then you should avoid any direct references to objects
within the modules to be reloaded.  Direct references are created by
statements like 'x = M1.x' or 'from M1 import x'.  Always access these
variables via the fully-qualified names, like M1.x, and you will avoid
leftover references to old objects after a reload.  This won't solve
the object creation problem, but at least it will avoid some surprises
when you re-use the variable x.

--- end of section ---

I *would* like to do something about numbers and strings and other
shared objects not getting updated, because that is going to be hard
to explain.  Maybe we could somehow switch off the generation of
shared objects for modules in a 'debug' mode.

-- Dave