Deprecating reload() ???

[Skip Montanaro]

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

    Dave> The goal is *not* to put the program into the state it "would have
    Dave> been" had the changes in M1 been done earlier.  That is
    Dave> impossible.  We simply want to have all *direct* references to
    Dave> objects in M1 be updated.  

The above looks like a pretty direct reference to M1.x. <0.5 wink>

It seems to me that you have a continuum from "don't update anything" to
"track and update everything":

    don't update       update global       update all direct      update
      anything         funcs/classes           references       everything

      reload()         super_reload()            Dave            nobody?

Other ideas have been mentioned, like fiddling the __bases__ of existing
instances or updating active local variables.  I'm not sure precisely where
those concepts fall on the continuum.  Certainly to the right of
super_reload() though.

In my opinion you do what's easy as a first step then extend it as you can.
I think you have to punt on shared objects (ints, None, etc).  This isn't
worth changing the semantics of the language even in some sort of
interactive debug mode.

Sitting for long periods in an interactive session and expecting it to track
your changes is foreign to me.  I will admit to doing stuff like this for
short sessions:

    >>> import foo
    >>> x = foo.Foo(...)
    >>> x.do_it()
    ...
    TypeError ...
    >>> # damn! tweak foo.Foo class in emacs
    >>> reload(foo)
    >>> x = foo.Foo(...)
    >>> x.do_it()
    ...

but that's relatively rare, doesn't go on for many cycles, and is only made
tolerable by the presence of readline/command retrieval/copy-n-paste in the
interactive environment.

Maybe it's just the nature of your users and their background, but an
(edit/test/run)+ cycle seems much more common in the Python community than a
run/(edit/reload)+ cycle.  Note the missing "test" from the second cycle and
from the above pseudo-transcript.  I think some Python programmers would
take the opportunity to add an extra test case to their code in the first
cycle, where in the second cycle the testing is going on at the interactive
prompt where it can get lost.  "I don't need to write a test case.  It will
just slow me down.  The interactive session will tell me when I've got it
right."  Of course, once the interactive sessions has ended, the sequence of
statements you executed is not automatically saved.  You still need to pop
back to your editor to take care of that.  It's a small matter of
discipline, but then so is not creating aliases in the first place.

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

Precisely.  You may wind up making reload() easier to explain in the common
case, but introduce subtleties which are tougher to predict (instances whose
__bases__ change or don't change depending how far along the above continuum
you take things).  I think changing the definitions of functions and classes
will be the much more likely result of edits requiring reloads than tweaking
small integers or strings.  Forcing people to recreate instances is
generally not that big of a deal.

Finally, I will drag the last line out of Tim's "The Zen of Python":

    Namespaces are one honking great idea -- let's do more of those!

By making it easier for your users to get away with aliases like

    x = M1.x

you erode the namespace concept ever so slightly just to save typing a
couple extra characters or executing a couple extra bytecodes.  Why can't
they just type M1.x again?  I don't think the savings is really worth it in
the long run.

Skip