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

[SourceForge.net]

Bugs item #1537167, was opened at 2006-08-09 08:01
Message generated for change (Comment added) made by loewis
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: Phillip J. Eby (pje)
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.




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

>Comment By: Martin v. Löwis (loewis)
Date: 2006-08-09 14:27

Message:
Logged In: YES 
user_id=21627

I'd say it is a bug that Python 2.4 allows non-dotted module
names for __import__. Can you come up with a change in
behaviour for "regular" module names?

As for cascading: path importers doe not cascade. Per
sys.path item, there can be at most one path importer. They
"cascade" in the sense that search continues with other
sys.path items if it wasn't found in one sys.path entry.
This cascading continues to work with 2.5.

Phillip, can you take a look?

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

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