Mailing-List: contact python-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: error (idunn.apache.osuosl.org: domain dscpl.com.au from
 203.16.214.182 cause and error)
In-Reply-To: <0ED7FDEF-FCC5-470F-AAE5-002613784760@emedialibrary.org>
References: <586C10B1-16E2-4F08-A017-D2199E9CCCEC@emedialibrary.org>
 <F4855E2C-C9B0-4BF7-8D7C-69C88D8773A1@dscpl.com.au>
 <355DBF2B-400C-4C47-8691-37829466F896@emedialibrary.org>
 <A44AD820-3776-4582-B95D-FD2DE425F485@dscpl.com.au>
 <0ED7FDEF-FCC5-470F-AAE5-002613784760@emedialibrary.org>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed
Message-Id: <C40AA213-B239-4E92-9FE4-91F4C66CC61C@dscpl.com.au>
Cc: python-dev@httpd.apache.org
Content-Transfer-Encoding: quoted-printable
From: Graham Dumpleton <grahamd@dscpl.com.au>
Subject: Re: Regex based publisher proposal
Date: Sun, 10 Sep 2006 16:51:35 +1000
To: =?ISO-8859-1?Q?S=E9bastien_Arnaud?= <arnaudsj@emedialibrary.org>


On 10/09/2006, at 12:28 PM, S=E9bastien Arnaud wrote:

> I love the wiki you put together, lots of great stuff in there! I =20
> am going to go back to the drawing board here due to all the new =20
> things you presented available in mod_python 3.3 which I did not =20
> know about. It looks like a fixuphandler would fit the bill for =20
> what I am attempting to do. Once I get something working, I will =20
> make sure to give more detailed info and a clear example of how the =20=

> framework/url matching works so that you can better advise on which =20=

> mod_python 3.3 features can be better taken advantage of.
>
> In regards to mod_python.publisher, it looks like indeed it is =20
> better to divorce myself from it after the points you brought up. =20
> On that topic though, should I reuse at all the ModuleCache object =20
> to load & cache modules? Or is there something more efficient/=20
> better in mod_python 3.3?

Ignore the ModuleCache class which appears to be used by =20
mod_python.publisher
as when the new importer gets used in mod_python 3.3 it doesn't =20
actually get used.

In mod_python 3.3, I would suggest you simply assume/require that the =20=

new module
importer is used and use apache.import_module() instead. The new =20
module importer
is the default in 3.3, but it still patches itself in in place of the =20=

old module importers
and so just reading the code everything still looks to use the old.

The most important things you will want to know about =20
apache.import_module() in
mod_python 3.3 are:

1. The first argument 'module' can actually now also be an absolute =20
path to a module
code file, including '.py' extension. By specifying the actual =20
location, you skip any
searching through directories trying to find an appropriate match.

2. You don't need to ever supply 'log' or 'autoreload' arguments as =20
the function is now
able to always get them directly from Apache configuration =20
information appropriate to
the request.

3. Because of (1), when using handler directives in Apache =20
configuration, you can
now supply an absolute path for a handler module file as well. Where =20
module file is
in non standard location, this avoids need to setup PythonPath. The =20
need to set up
PythonPath explicitly should be much reduced and using it couldn't =20
indicate a wrong
setup and you might even find mod_python complaining about it.

You can check out some of the behaviour of the new module importer by =20=

reading
the old mailing list thread at:

   http://www.modpython.org/pipermail/mod_python/2006-April/020936.html
   http://www.modpython.org/pipermail/mod_python/2006-May/021097.html
   http://www.mail-archive.com/python-dev@httpd.apache.org/msg02185.html

There are lots of details though and not sure that these capture it =20
all. I still need to
turn this all into a wiki page as well and use some of it for =20
official mod_python docs. :-)

Graham=