Graham Dumpleton commented on MODPYTHON-143:

Going to be a pain and change the name of the PythonOption used to enable the 
new importer. The reason for this is that I am coming to the belief that making 
the new importer the default in mod_python 3.3 is probably not a good idea. 
Instead, mod_python 3.3 when released should allow both to exist with the 
default being the old importer. When the user is ready, they can make a 
conscious decision to turn on the new importer and then modify their code if 
necessary to ensure it works.

The thinking here is that even though we may be able to produce some really 
good documentation that says how the new importer works, many aren't going to 
bother to check the documentation and ensure their code works first. Some may 
not even have a choice given that it may be dictated by an ISP who makes the 
decision to install the new version. Also, you have projects like Django which 
rely on mod_python working in a certain way and there will probably be a lot of 
complaints if we dump out a new version of mod_python which breaks it in some 
way. Depending on their release schedules they may not be in a position to 
release an updated version quickly. Thus we need to allow for a transition 
period where both options exist in an official release version, we can't expect 
people to use the version out of subversion, or even final test tar balls.

As to turning on the new importer as the default, I would suggest that after 
mod_python 3.3 is out and bedded down, then we make a swap as to which is the 
default importer and release it as a new major version 4.0 so as to clearly 
signify that there are sufficient differences in how parts of the importer 
work. The old importer could be removed from the code in some future version 
after that.

This new major version could also be a good point to drop default support for 
old option names as talked about in MODPYTHON-127.

That all said, the new PythonOption I am going to use is:


The argument to the option would be as before. That is "*" for all 
interpreters, or a comma separated list of interpreters. The option will still 
need to be defined at global scope in main Apache configuration outside of all 
configuration containers.

On this basis I will now make some of the changes to the C code bits of 
mod_python which need to be made so that new importer works properly in all 
cases. Such code though will only be run when the above option lists the 
interpreter the request is executing in. I'll also have to make the test 
harness suite be able to cope with running extra tests only for the new module 
importer, so how new importer is enabled in the test suite will change as well.

> Implement and integrate a new module importer.
> ----------------------------------------------
>          Key: MODPYTHON-143
>          URL: http://issues.apache.org/jira/browse/MODPYTHON-143
>      Project: mod_python
>         Type: Task

>   Components: importer
>     Versions: 3.2.8
>     Reporter: Graham Dumpleton
>     Assignee: Graham Dumpleton

> This is an overall task to cover the issue of rectifying the various module 
> importer issues by replacing it with a new implementation. A description of 
> the various problems can be found in:
>   http://www.dscpl.com.au/articles/modpython-003.html
> Separate issues had already been created for some of the specific problems. 
> These issues will now be linked to this problem and thus marked as being 
> dependent on this issue.
> In other words, replacing the module importer will solve a number of number 
> issues. Rather than try and keep up to date all the separate issues, all 
> information about the replacement will be put against this issue instead.
> Note that there are also some issues which are not directly related to the 
> module importer but which will be made dependent on this issue because it is 
> easier to fix the issue as part of the rewrite of the module importer and top 
> level handler dispatch mechanism than it is to address it as a distinct item.
> In respect of what impacts the new module importer implementation may have 
> and how it is used may change, this will be documented in the following 
> document for the time being:
>   http://www.dscpl.com.au/articles/modpython-007.html
> Note that this document is a work in progress. It is dense reading and 
> assumes you know a bit about the current module importer and its problems. 
> Any significant issues raised by this document can be added here as a 
> comment, or if a general dicussion of a topic is needed, raise the issue on 
> the mod_python developers mailing list.
> A possible new implementation for the module importer is basically ready for 
> testing and experimentation. The intent is to push it into the mod_python 
> source tree, but for its use to be optional. 
> If wanting to enable it for a specific Python interpreter, the PythonImport 
> directive would be used:
>   PythonImport mod_python.future.importer mytestinterpreter
> If wanting to enable it for all Python interpreters, a PythonOption directive 
> would be used at global scope within the Apache configuration. Ie., outside 
> of all Location, Directory or Files container directives. The exact option 
> name to be used hasn't yet been decided.
> More details and announcements at the appropriate time.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

Reply via email to