[Import-SIG] PEP 382: Partial packages

"Martin v. Löwis" martin at v.loewis.de
Tue Jul 12 08:03:59 CEST 2011

> Because only in Python does a search for "foo/bar" (whatever the
> separator) *stops* the path search when there is a match for "foo/".  In
> PHP, Perl, and Java, searching continues along the path until the entire
> target is matched, regardless of whether the name parts are separated by
> slashes (PHP), dots (Java), or double-colons (Perl).
> That's why Python's behavior here is arguably a misfeature.

Hmm. For PHP, I don't think it's better, just different - you can
*never* include a directory, so the directory is not a recognized entity
in the include mechanism at all. It's the file system that is
hierarchical, not the PHP namespace concept (except for new-style
namespaces, which we seem to agree are unrelated).

> For example, in Java, the class org.Foo is distinct from the namespace
> org.Foo.* in on-disk representation, as you have org/Foo.java (or
> .class) sitting outside the directory org/Foo/ (where any contents of
> org.Foo.* would be located.

Not true; see the attached example. Compiling foo/baz.java gives

foo/baz.java:6: cannot find symbol
symbol  : variable foobar
location: class foo.bar

It decides that foo.bar is a class (from foo/bar.java), so
foo.bar.foobar should be something inside the class (such as a nested
class), and the package foo/bar is not considered anymore. If you delete
bar.java, and refer to foo.bar1.V instead in baz.java, it compiles.

IOW, you can't have a class and a package with the same name in Java.

> Similarly in Perl, Foo.pm sits outside the Foo/ directory, thereby
> distinguishing Foo and Foo::.

I agree that this is better.

> If Python were following the model of these other languages, then
> instead of using zope/__init__.py, we would place a zope.py in the
> parent directory, and when importing zope.interface, we would search the
> entire path for zope/ subdirectories containing an interface.py...  but
> we wouldn't look for interface/ directories until/unless we tried to
> import zope.interface.foo.

I think it can actually work, and will propose a PEP (wording) in that
direction shortly.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: foo.tar
Type: application/x-tar
Size: 10240 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/import-sig/attachments/20110712/77c1a21a/attachment-0001.tar>

More information about the Import-SIG mailing list