[Python-3000] Import system questions to be considered for Py3k

[Josiah Carlson]

Ka-Ping Yee <python at zesty.ca> wrote:
> 
> On Sun, 16 Jul 2006, Nick Coghlan wrote:
> > Taking the "import system" to be the overall interaction between the
> > Python module namespace and the file system of the underlying computer,
> > I thought I'd start compiling a list of the questions we'll want to
> > consider for Py3k.
> 
> I'd like to add "reloading" to your list.  Updating a Python interpreter
> such that it reflects changes in module files is currently quite
> difficult.  Calling reload() works somewhat for a single module if
> it has no dependencies, but beyond that the problem gets very tricky.
> 
> It would be nice if we had a design that made it possible to achieve
> such an update (even if it were expensive to do -- it would be nice
> just to be able to identify the steps one would have to take to be
> confident that everything was up to date).  If that's too much to ask,
> i think we should at least be able to say under what conditions we
> expect reloading to work (e.g. is it possible to write programs in
> a style that makes reloading feasible?) and/or what guarantees a
> realod will make or not make.
> 
> A coherent reloading model is one of the huge advantages that PHP
> currently has over Python that contributes to the hurdles blocking
> Python's use for lightweight web scripting.  When the context is
> rapid prototyping, it is perhaps *the* killer advantage, outweighing
> all the other flaws in PHP's language design.

I'd first start out by claiming that reload() works.  That is, you can
reload a specified module, and that should really be the only change in
modules.  It sounds to me like you want a recursive reload() such that
when you are reloading moduleX that imports non-system moduleY, that
Python also reload moduleY.

While I agree that such a thing would be convenient, especially in the
realm of web frameworks, etc., it wouldn't necessarily solve the 'stale
code' problem, because it doesn't necessarily update all references to
that module or its contents due to from imports.  What may or may not be
more effective is to only ever use references to modules in local scopes,
which are generated from another object that verifies the "most recent
version" nature that a web framework would necessitate.

That is, one could access a reloader via attributes, which will
dynamically reload modules as necessary...

    DR.moduleX.moduleY.classZ

DR would check the 'currentness' of moduleX on access, check the
'currentness' of moduleY, and would note that classZ was not a module in
the most recent moduleY, so would return it.  For gaining non-dynamic
references, one could even offer a moduleY = getmodule(DR.moduleX.moduleY) . 
From this semantic, it is a (somewhat tedious) matter of writing the
implementation of DR, and replacing imports with the above references.

While it still wouldn't be optimal, it's significantly better than the
current alternatives (even a recursive reload).

 - Josiah