Deprecating reload() ???

[David MacQuigg]

On Tue, 16 Mar 2004 04:43:01 GMT, Carl Banks
<imbosol at aerojockey.invalid> wrote:

>What if one of your users does something like 'y = M1.x + 1'; then
>what are you going to do?

The goal is *not* to put the program into the state it "would have
been" had the changes in M1 been done earlier.  That is impossible.
We simply want to have all *direct* references to objects in M1 be
updated.  A direct reference, like 'y = M1.x', sets 'y' to the same
object as 'M1.x'  The 'y' in the above example points to a new object,
with an identity different than anything in the M1 module.  It should
not get updated.  

>It seems to me that your noble effort to make reload() completely
>foolproof is ultimately in vain: there's just too many opportunities
>for a module's variables to affect things far away.

It all depends on your goals for reload().  To me, updating all direct
references is a worthy goal, would add a lot of utility, and is easy
to explain.  Going further than that, updating objects that are "only
one operation away from a direct reference" for example, gets into a
grey area where I see no clear line we can draw.  There might be some
benefit, but the cost in user confusion would be too great.  

Reload() will always be a function that needs to be used cautiously.
Changes in a running program can propagate in strange ways.  "Train
wreck" was the term another poster used.

-- Dave