Only one level of namespace package nesting is handled correctly:$ unzip -l foo.zipArchive:  foo.zip  Length      Date    Time    Name---------  ---------- -----   ----        0  2013-04-03 17:28   a/b/c/foo.py        0  2013-04-03 17:34   a/        0  2013-04-03 17:34   a/b/        0  2013-04-03 17:34   a/b/c/---------                     -------        0                     4 files$ lsfoo.zip$ PYTHONPATH=foo.zip ~/dev/cpython/pythonPython 3.4.0a0 (default:3b1dbe7a2aa0+, Apr  3 2013, 17:31:54) [GCC 4.8.0] on linuxType "help", "copyright", "credits" or "license" for more information.>>> import a>>> import a.bTraceback (most recent call last):  File "<stdin>", line 1, in <module>ImportError: No module named 'a.b'>>>The problem appears to be that check_is_directory constructs the wrong directory path (it should be 'a/b'):check_is_directory (self=0x7ffff6d3dc88, prefix='a/', path='a.b')    at ./Modules/zipimport.c:280280     dirpath = PyUnicode_FromFormat("%U%U%c", prefix, path, SEP);(gdb) n281     if (dirpath == NULL)(gdb) p dirpath$11 = 'a/a.b/'I've attached a tentative initial patch that appears to fix the issue, although it probably needs some more thought (and definitely some more testing - the existing tests still pass though).

Could you construct a test (that would fail without your patch)?Thanks.

Here's a test that fails without the patch and succeeds with the patch.

The attached patch is ready for review.

Updated patch with markups suggested by Serhiy.

I have expanded on theissue17633-2 patch to fix an issue with the enumerated value returned by find_loader().  The patch (issue17633-3.diff) is against 3.5.1.  I have also added more test cases that cover spreading a namespace package across two zip files and between a zip file and a filesystem.  The expanded tests cover the iterable __path__ member of a namespace package.  No new failures in 'make test'  (gdb and ssl were broken with in 3.5.1 before this patch).  The expanded test cases should continue to be relevant even if zipimport is rewritten.

Any chance you can do the diff against an hg checkout, Mike? That way we can use our review tool to do the code review, else we have to work only from the raw diff file which isn't as nice.

Yes.  I can do this.  I've not used hg before.  But I bet I can figure it out.  I'm assuming hg has a diff/pach genterator of some kind ('hg diff' perhaps).  Lemme try and find the hg repository and check out a copy...

Tryissue17633-hg.diff.   Caution it was made after literally minutes of experience with hg.  :)  I checked out the source applied the changes, compiled and ran 'make test' (gdb still fails), and did an hg commit.  The diff was made following the instructions here:https://docs.python.org/devguide/gitdevs.html  It seems to have worked.  But again, I have literally minutes of hg experience.  If this needs to be redone let me know.

Nope, looks like it worked! I will try to have a look at the patch some time this week.And for future reference, you can also usehttps://docs.python.org/devguide/patch.html as a guide.

This patch modifiesissue17633-hg.diff by adding changes suggested by the reviewers.  Note.  I did cleanup the use of __import__ outside of the area involved withissue17633 as it seemed low risk.  The tests forissue17633 (and the refactored doTest/makeZip now use addCleanup().  However there are still tests in the module that use the old try/finally way of cleanup.  I did not modify these in order to keep this from being a rewrite of test_zipimport.  But if more changes are desired, I'll add them.

The fix for 3.5 is inhttps://hg.python.org/cpython/rev/07a615a8f9ad and 3.6 inhttps://hg.python.org/cpython/rev/87f87673af7b.Thanks to Phil and Mike for tackling this problem!

New changeset07a615a8f9ad by Brett Cannon in branch '3.5':Issue#17633: Improve support for namespace packages with zipimport.https://hg.python.org/cpython/rev/07a615a8f9adNew changeset87f87673af7b by Brett Cannon in branch 'default':Merge for issue#17633https://hg.python.org/cpython/rev/87f87673af7b