[ http://issues.apache.org/jira/brows...242
7741 ]

Graham Dumpleton commented on MODPYTHON-143:
--------------------------------------------

An issue which still needs to be looked at with new module importer is that 
for historical reasons, the __name__ attribute put in modules is concocted f
rom an md5 hash of the full pathname of the module file. The reasons for thi
s is that the implementatio
n that the importer was based on attempted to still store modules in sys.mod
ules and in doing so the module name couldn't contain various characters tha
t can appear in pathnames, eg, slash, colon etc. This way of setting up the 
module name has persisted a
nd not been changed.

Problem is that it seems that use of certain third party packages can well a
nd truly stuff up md5 generation in Python. See:

http://www.modpython.org/pipermail/...une/021482.html

and all the followup posts.

This may not be a big issue in as much as you probably do not want to try an
d be resilient to such a problem, as for md5 hashes it would be very importa
nt for any underlying problem to be fixed.

Now the __name__ attribute in modules could possibly be replaced with the na
me of the file, ie., the same as __file__, but could there be other code out
 there which makes assumptions about what sort of characters appear in the _
_name__ attribute and rely
on that somehow.

> Implement and integrate a new module importer.
> ----------------------------------------------
>
>                 Key: MODPYTHON-143
>                 URL: http://issues.apache.org/jira/browse/MODPYTHON-143
>             Project: mod_python
>          Issue Type: Task
>          Components: importer
>    Affects Versions: 3.2.8
>            Reporter: Graham Dumpleton
>         Assigned To: Graham Dumpleton
>
> This is an overall task to cover the issue of rectifying the various modul
e importer issues by replacing it with a new implementation. A description o
f 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 d
ependent on this issue.
> In other words, replacing the module importer will solve a number of numbe
r issues. Rather than try and keep up to date all the separate issues, all i
nformation 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 dispat
ch
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 doc
ument 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 issu
es 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 f
or 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 PythonImpor
t directive would be used:
>   PythonImport mod_python.future.importer mytestinterpreter
> If wanting to enable it for all Python interpreters, a PythonOption directive woul
d be used at global scope within the Apache configuration. Ie., outside of all Locat
ion, Directory or Files container directives. The exact option name to be used hasn'
t y
et been decided.
> More details and announcements at the appropriate time.

[ Post a follow-up to this message ]