Deprecating reload() ???
dmq at gain.com
Tue Mar 16 12:48:49 CET 2004
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.
More information about the Python-list