Deprecating reload() ???

[John Roth]

"David MacQuigg" <dmq at gain.com> wrote in message
news:fc0c50htlip4mtpjjdhbuenn6m38o3mi9u at 4ax.com...
> On Mon, 15 Mar 2004 11:33:04 -0600, Jeff Epler <jepler at unpythonic.net>
> wrote:
>
>
> It's worse than just a misunderstanding.  It's a serious limitation on
> what we can do with editing a running program.

Well, that's a definite yes and no. The limitation is quite simple:
any object in the module that has a reference from outside of the
module will not have that reference changed. It will continue to
refer to the old copy of the object.

The solution to this is to apply some design discipline. Systems
exist that have absolute "cannot come down for any reason"
type of requirements where software has to be replaced while the
system is running. It's not impossible, it simply requires a great
deal of discipline in not allowing references to wander all over the
place.

As far as updating in place while debugging, there are a few
solutions that, so far, haven't been implemented. One is to
notice that functions are objects that have a reference to another
object called a "code object." This is the actual result of the
compilation, and if you go behind the scenes and replace the
code object reference in the function object, you've basically
done an update in place - as long as you don't have a stack
frame with a pointer into the old code object! (The stack frame
could, of course, be fixed too. Extra credit for doing so.)

I can easily imagine a development environment that could
do this kind of magic. If someone wants to build it, I'm
certainly not going to stop them (and wouldn't even if I could.)
I might even find it useful!

The thing that is not going to work, ever, is having reload()
do the work for you.

> I don't agree that
> what it does now is well defined (at least not in the documentation).

It's well enough defined for someone who knows how Python works.

> The discussion in Learning Python is totally misleading.  We should at
> least update the description of the reload function in the Python
> Library Reference.  See the thread "Reload Confusion" for some
> suggested text.

I agree with that: instead of "There are some caveats" it should say:

WARNING - references to objects in the old copy of the module
that have leaked out of the module will NOT be replaced. A few of
the implications are:

and then continue with the current text (my version of the doc is 2.3.2).

John Roth
>
> -- Dave
>