[Import-SIG] PEP 382: Partial packages

"Martin v. Löwis" martin at v.loewis.de
Mon Jul 11 08:53:21 CEST 2011

>> No - it is actually what makes it a package. There are two ways to
>> declare a package: either put an __init__.py into the directory, or
>> a .pyp file.
> It's too bad that (for backward compatibility reasons) we can't just use
> the presence of any importable file to signify this, as is the norm for
> Java, Perl, PHP, etc.

I'm not sure I understand:
- in Java, a package is not an importable file, but a directory,
  just as in Python. The major differences are:
  * empty directories count as packages as well; they just have to
    be on the CLASSPATH
  * you can't import packages in Java - you can only import classes
- in PHP, namespaces and files are completely unrelated:
  The files you want to use are passed to "include". include takes
  file names, not namespace names. Only after including the file,
  PHP finds out what namespace the stuff is in it imported.
- in Perl, the parent package and the subpackages appear unrelated.
  The parent package is a file "foo.pm"; the subpackages are files
  in a folder "foo"; in addition, each module needs to declare
  its package (i.e. "package foo;" or "package foo::bar;"). This
  automatically makes "composite packages" possible (as the
  subpackages are just not considered "parts" of the parent package,

> (AFAIK, all of them have namespacey packages by default.)

Please stop calling this "composite" feature "namespacey".


"In general, a namespace is a container that provides context for the
identifiers (names, or technical terms, or words) it holds, and allows
the disambiguation of homonym identifiers residing in different

*All* Python packages are namespaces. What specific property of the
package mechanism do you mean when you say "namespacey"?


More information about the Import-SIG mailing list