[Import-SIG] What if namespace imports weren't special?
ncoghlan at gmail.com
Mon Jul 11 06:22:54 CEST 2011
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"
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
>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.
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Import-SIG