[Import-SIG] Is ".ns" really the right extension?
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
> 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
> (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.contrib <- marks this as a namespace package portion
> ProxyTypes.contrib <- same for 'peak.util'
> Importing.contrib <- marks this as a namespace package portion
> Importing.contrib <- same for 'peak.util'
> site-packages/ (or wherever)
> ProxyTypes.contrib <- both distributions' contributions are
> Importing.contrib <- at both levels
> 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
More information about the Import-SIG