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. -- ?!ng _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
