[Import-SIG] PEP 382 update

["Martin v. Löwis"]

> I believe the PEP 402 approach is much cleaner: both foo.py and
> foo/__init__.py would stop the sys.path scan *immediately* (thus
> eliminating any performance impact on existing imports), but
> subpackage imports ("import foo.bar" or "from foo import bar") will
> attempt to either convert an existing "foo" module into a package, or
> else create a new package, by scanning the whole of sys.path for
> "foo.pyp" directories. The "foo/__init__.py" approach would create
> self-contained packages that are explicitly closed to extension.

I think that's under-specified in PEP 402. It doesn't classify
"from foo import bar" as a subpackage import, since it states that
this magic only applies to imports involving dotted names. So which
imports trigger this path scanning exactly remains to be specified.

Performance-wise, I would expect that PEP 382 is more efficient
if the package has code in it, and not worse for "pure"
namespace packages. If there is code in the package, with PEP 402,
you would have to provide a P.py file, and multiple P.pyp directories.
On importing P, it searches the path finding P.py. On importing
a sub-package, it searches the path *again* to establish the package's
__path__. With PEP 382, there is only a single run over the path.
PEP 402 might be more efficient for P/__init__.py packages.

I'm skeptical that it matters much: the majority of stat calls
comes from the many forms of module files, which neither PEP 382
nor PEP 402 would stat after the first hit. PEP 382 might be slightly
more efficient here, since a .pyp directory early on the path would
already cancel stat calls for module files (.py, .pyc, .pyd, module.pyd,
...). For a namespace package, PEP 402 would scan the
entire path for all kinds of modules, even if it eventually turns out
that it is only going to use the .pyp directories it has already seen.

Regards,
Martin