quetz-mod_python-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Dumpleton <grah...@dscpl.com.au>
Subject Re: Solving the import problem
Date Wed, 08 Jun 2005 22:27:18 GMT

On 09/06/2005, at 8:04 AM, Nick wrote:

> Graham Dumpleton wrote:
>> On 09/06/2005, at 12:29 AM, Nick wrote:
>>> but I just want to be clear that I don't think mod_python should 
>>> install any import hooks.  That would probably be annoying to 
>>> seasoned Python programmers, and really a pain in the butt for me 
>>> specifically.
>> Curious to know why you think this would be annoying to seasoned 
>> Python
>> programmers and a pain in the butt to yourself.
>
> As I mentioned before, as a programmer I would want mod_python to be 
> an API for apache in Python, with no special alteration of how Python 
> works as advertised in the Python documentation.  Installing import 
> hooks bypasses the Python import functionality as it's documented, and 
> in my opinion is not necessary to use mod_python as an API for apache.

The apache.import_module() method is already currently used to perform 
the
top level import of a handler module and already behaves differently to 
a
standard "import", so even without an import hook you already have a 
problem.

> While it may be convenient for some people to have an import hook that 
> will automagically reload a module when it changes on disk, that's 
> *not* how Python works, and would be unexpected behaviour for a Python 
> programmer. That's like saying that since most people want to parse 
> the input stream as form data, let's automatically parse it and put it 
> into req.form.  But mod_python doesn't do that.  You have to use 
> utils.FieldStorage.

FWIW, if you use mod_python.publisher form parameters are always 
decoded into
req.form regardless of whether you use them and actually can cause a 
few problems.
In Vampire I have demonstrated though that lazy form evaluation can be 
implemented,
with form parameters only being decoded in the prototype if the handler 
actually
indicates by way of defining form arguments that it wants them.

> For my own applications I take advantage of Python's internal import 
> routine because it is in C and therefore much faster than any pure 
> Python implementation (try benchmarking an import hook in ihooks and 
> you'll see how slow it is).

The ihooks module is deprecated and is not used in any way in the new 
style import
hooks mechanism in Python. The new style import mechanism is still 
almost all written
in C from what I can tell, with call outs to Python code only in those 
specific spots
where the now minimal hooks are allowed for a user defined module 
importer and loader.
It isn't as bad as you make out, the general runtime cost of your own 
code, Apache
and network I/O is still going to greatly exceed any minor cost of the 
import hooks.

> I want to inspect sys.modules, and that's where I expect imports to 
> go.  I don't want to bypass an import mechanism that works differently 
> just to get back to Python's; that's counter-intuitive.  Plus, it'll 
> make reuse a pain, because I'll have to write modules with special 
> checks to see if I'm in mod_python or do something else when not.

As I mentioned before, the import hook would only come into play in a 
specific
context. It doesn't touch normal imports of stuff from the Python 
installation
or site packages directory, or in practice any modules of your own 
which you have
placed on sys.path somewhere. As such, no special checks are required, 
as general
utility modules wouldn't make use of it.

The intent is that the import hooks are a convenience in some very 
specific
cases related to the handler modules as they reside in document tree. 
The idea
is that in general people wouldn't rely on them. You cannot get away 
from using
it though if you want to use a package like Cheetah Templates and still 
want
to use automatic module reloading, as it generates code which uses 
"import"
and it isn't possible to change that to use a mod_python specific module
loading function unless you are prepared to rewrite bits of Cheetah 
itself.

> I just don't think default import hooks are necessary to make 
> mod_python generally useful to people.  I can certainly understand 
> people's needs for something more flexible than Python's stock 
> importer when writing applications, and there's always an option to 
> add a module to mod_python that can let people do exactly that.  I 
> just don't want it out of the box.

Even in Vampire where I have the import hook stuff working, it isn't on 
by default
and I would not suggest that it should be on by default.

Graham


Mime
View raw message