[Import-SIG] What if namespace imports weren't special?

[Nick Coghlan]

On Mon, Jul 11, 2011 at 1:57 PM, P.J. Eby <pje at telecommunity.com> wrote:
> I'm noticing, though, that the more I hear "partitioned package", the less I
> like it, and the more I wish I hadn't proposed it.  ;-)
>
> It's fundamentally wrong, because (e.g.) peak.util is *not* a single thing
> that's been partitioned, *even though* it started out that way.
>
> It's just a bunch of things with a common namespace, and ISTM the name
> *really* ought to reflect that.
>
> Common namespace packages?  Shared namespace packages?  Surname packages?
>  ;-)

As soon as you have a flat namespace, you need to be careful to
partition it correctly. We run into that fairly often with namespace
collisions at the top level - failures of partitioning because (for
example) a user decided to call their "experimenting with sockets"
file "socket.py".

So the "partitioned package" naming is a developer oriented view
pointing out that hey, you're putting these files into a namespace
shared with other people so think about the implications that may have
for the name you choose (just as you would for a top-level package or
module name or for a script symlink that is going to be placed into
/usr/bin).

>From a *user* point of view, they shouldn't care whether a package is
partitioned or not - they'll just be treating it like an ordinary
package, since (in theory) you can't tell the difference without
poking around inside __path__.

There may be a slight implication that all the partitions came from a
single source that has been split up, but I don't think the single
source implications are strong enough to invalidate the term. Anything
that gets put into "peak.util" is going to relate to PEAK in *some*
fashion, even if it isn't distributed as part of PEAK itself.

Certainly, I haven't seen anything else suggested that comes close to
this one for accuracy and mnemonic value.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia