[ python-Bugs-1537167 ] 2nd issue with need for speed patch

[SourceForge.net]

Bugs item #1537167, was opened at 2006-08-09 07:01
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1537167&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Robin Bryce (robinbryce2)
Assigned to: Nobody/Anonymous (nobody)
Summary: 2nd issue with need for speed patch

Initial Comment:
This is not a duplicate of the "realease manager
pronouncement on 302 Fix needed" issue raised on pydev.

If a custom importer is present, import.c skips the
builtin import machinery if the find_module method of
that  importer returns None. For python 2.4.3 if
find_module returns none the normal builtin machinery
gets a lookin. The relevent change was the addition of
a continue statement with svn commit r46372 (at around
line 1283 of import.c on the trunk). 

I don't understand, in the face of this change, how pep
302 importers are expected to cascade. returning None
from find_module is the way an importer says "no I
can't load this module but I cant say for certain this
means ImportError" isnt it ?

One (unintended?) consequence of this change is the
following corner case:

As __import__ allows non dotted module names
__import__('fakemod.a/b') *will* succede on python
2.4.3 provided b is a directory under the package a
that contains an __init__.py. In python 2.5b3 this fails.

I've atatched a detailed repro case of this particular
corner case.




----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1537167&group_id=5470