re-importing modules

[Chris Mellon]

On 5/1/07, John Nagle <nagle at animats.com> wrote:
> Steven D'Aprano wrote:
> > I'd hate for reload to disappear, it is great for interactive
> > development/debugging, at least under some circumstances. (If you have
> > complex and tangled class hierarchies, it might not be powerful enough.)
> >
> > As for the semantics being awful, I disagree. reload() does exactly
> > what it claims to do, no more, no less.
>
>      It's more complicated than that.  See
>
>        http://arcknowledge.com/lang.jython.user/2006-01/msg00017.html
>
> Exactly what reloading should do is still an open question for some of
> the hard cases.
>
>      "reload" as a debug facility is fine.
> Trouble comes from production programs which use it as a
> reinitialization facility.
>
>      Reloading a module with multiple threads running gets
> complicated.  It works in CPython because CPython doesn't have
> real concurrency.  Insisting that it work like CPython implies
> an inefficient locking model.
>
>                                         John Nagle
> --

Not really. The problem is when people attempt to overload the
current, existing reload() semantics (which are sensible and simple
once you understand that they don't attempt magic, although people
tend to expect the magic and they're non-intuitive in that manner).
There shouldn't be any problem implementing reload() in anything that
implements import.

The problem is with the fancier, magical imports that people keep
expecting reload() to be, and thats what both the links you've
provided are attempting to write. There's potentially a place for that
sort of reload(), but it clearly can't have the semantics that the
current reload does, and it suffers from all the same problems that
hotpatching systems always have - that it's not always clear how they
should work or what they should do, and you need a very tight
specification of how they will work in all the corner cases, including
threading. But that's got nothing to do with the current reload(),
which is simple, straightforward, and easily implemented.

The GIL isn't important in this respect - there's nothing complicated
about reload() that isn't also complicated about import. You either
have thread-local modules (which is probably stupid, because it can
result in all sorts of crazy behavior if you pass objects defined in
different versions of the same module between threads) or you
serialize import and access to sys.modules (or whatever your
underlying implementation of the module cache is).