[Import-SIG] PEP 382: Partial packages

P.J. Eby pje at telecommunity.com
Mon Jul 11 00:30:27 CEST 2011

At 11:57 PM 7/10/2011 +0200, Martin v. Löwis wrote:
> > Partial package works for me. I too like the association with partial
> > classes. ".pyp" is okay, although I'd avoid saying it stands for "Python
> > Package", since the presence of the file is not what makes this code a
> > package, it makes it a partial package.
>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.  (AFAIK, all of them have namespacey 
packages by default.)

In any case, I agree with Barry and Brett that "partial packages" 
conveys the wrong impression, as it puts emphasis on what is missing 
rather than what is there.

I want to suggest alternatives such as "compilation package" or some 
such to indicate that the package is a compilation of contributions, 
but that sounds like it's going to be compiled to assembly code or 
something.  ;-)

Frankly, though, I have no strong motivation to change the name; I'd 
honestly rather drop __init__ support as it's technically difficult 
and an invitation to problems anyway.  ;-)

I'm okay with some bikeshedding on the file extension, but unless 
somebody really comes up with a truly *excellent* replacement for 
"namespace package", I don't see much point to changing it.

I will go ahead and throw in a few ideas, none of which I think are 
necessarily *excellent*, but which seem like they might work:

  * multipart packages (packages that can be divided into separately 
installed/distributed parts)
  * package families (a group of packages that share a "family name")
  * organization packages (package whose purpose is to organize other 
packages, and/or indicate organizational authorship)
  * partitioned packages (packages that can be divided into 
separately installed/distributed parts)


(Oh, btw, I'm a long-time Windows user and I see zero technical or 
cultural problems with having a longer-than-three extension.  It's 
increasingly common to see apps using them; even Microsoft now has 
'.docx' files in Office.  So, for the first and last naming schemes 
above I would lean towards ".pypart" as the extension.)

More information about the Import-SIG mailing list