[Import-SIG] Is ".ns" really the right extension?

Eric Snow ericsnowcurrently at gmail.com
Sun Jul 10 00:58:14 CEST 2011

On Sat, Jul 9, 2011 at 3:20 PM, P.J. Eby <pje at telecommunity.com> wrote:
> Looking over the example code I added to the PEP draft (based on Barry's
> suggestion), it occurs to me that, like his example, mine is still
> confusing.
> And, now that I look more closely at it, I see that the confusion in large
> part comes from the idea of naming something "ThisPart.ns" -- it implies
> that "ThisPart" is the namespace!
> And it's not a namespace at all.  It's really a portion of the namespace.
> It seems to me that what the actual meaning of a foo.ns file is, "The 'foo'
> portion of the this namespace is installed here".  And that thus,
> foo.portion or foo.part or foo.contribution something like that would be
> more appropriate, given the PEP terminology.
> I think that a change is needed here to make the PEP's narrative come
> together more cleanly.  I'm leaning towards calling them foo.contrib files,
> as in "The 'foo' distribution contributed to this portion of the enclosing
> package."
> (Among other things, this makes the need for repeated files clearer; i.e.,
> you add a contribution marker to each package directory you're putting files
> or subdirectories into.)
> Overall, the narrative can then lose the constant references to *.ns files
> and instead talk about contribution markers -- i.e. a namespace package
> portion is a directory containing one or more contribution markers.  I think
> this will be clearer than the current text, and in particular it should make
> the example directory layout more meaningful to read.
> Notice, too, that Eric Snow's confusion about how .ns files work seems to
> have been influenced by the terminology -- i.e., the expectation that a
> 'zope.ns' file was talking about a 'zope' namespace package and identifying
> the containing directory as part of the namespace, rather than the other way
> around.  Was that the case, Eric?  And if so, do you think that these
> layouts are any clearer?

Yeah, that is spot on.  I definitely had it backwards.  Those examples
make _much_ more sense now, particularly because of the different
extension, and partly from your and Nick's explanations.

>    ProxyTypes-0.9.tgz:
>        peak/
>            ProxyTypes.contrib <- marks this as a namespace package portion
>            util/
>                ProxyTypes.contrib   <- same for 'peak.util'
>                proxies.py
>    Importing-1.10.tgz:
>        peak/
>            Importing.contrib   <- marks this as a namespace package portion
>            util/
>                Importing.contrib   <- same for 'peak.util'
>                imports.py
>    site-packages/   (or wherever)
>        peak/
>            Importing.contrib
>            ProxyTypes.contrib   <- both distributions' contributions are
> merged
>            util/
>                Importing.contrib   <- at both levels
>                ProxyTypes.contrib
>                imports.py
>                proxies.py
> Any other thoughts?

If two contributions are added into the same directory (a la that last
example) is there a way of telling programatically what portions came
from which contribution?

Also, if two contributions are made to a namespace package on the same
sys.path entry, they must go into the same directory, right?  Is there
a way around that, like using zip files or something (might we find
all three above examples in site-packages)?  The idea of having them
in separate plain directories (without __init__.py) for the same
sys.path entry is part of what motivated my earlier confusion.

Finally, say a portion is "contributed" to an existing non-namespace
package [directory], turning it into a namespace package.  The package
is then impacted by PEP 382 (particularly regarding __init__.py) when
it may not have been developed for use as a namespace package.  Is
this case worth considering?


> _______________________________________________
> Import-SIG mailing list
> Import-SIG at python.org
> http://mail.python.org/mailman/listinfo/import-sig

More information about the Import-SIG mailing list