At 03:58 AM 4/17/2009 +0000, gl...@divmod.com wrote:
Just as a use-case: would the Java "com.*" namespace be an example
of a "pure package with no base"? i.e. lots of projects are in it,
but no project owns it?
Er, I suppose. I was thinking more of the various 'com.foo' and
'org.bar' packages as being the pure namespaces in question. For
Python, a "flat is better than nested" approach seems fine at the moment.
Just to clarify things on my end: "namespace package" to *me* means
"package with modules provided from multiple distributions (the
distutils term)". The definition provided by the PEP, that a
package is spread over multiple directories on disk, seems like an
implementation detail.
Agreed.
Entries on __path__ slow down import, so my understanding of the
platonic ideal of a system python installation is one which has a
single directory where all packages reside, and a set of metadata
off to the side explaining which files belong to which distributions
so they can be uninstalled by a package manager.
True... except that part of the function of the PEP is to ensure that
if you install those separately-distributed modules to the same
directory, it still needs to work as a package and not have any
inter-package file conflicts.
Of course, for a development installation, easy uninstallation and
quick swapping between different versions of relevant dependencies
is more important than good import performance. So in that case,
you would want to optimize differently by having all of your
distributions installed into separate directories, with a long
PYTHONPATH or lots of .pth files to point at them.
And of course you may want a hybrid of the two.
Yep.
So another clarification I'd like in the PEP is an explanation of
motivation. For example, it comes as a complete surprise to me that
the expectation of namespace packages was to provide only
single-source namespaces like zope.*, peak.*, twisted.*. As I
mentioned above, I implicitly thought this was more for com.*,
twisted.plugins.*.
Well, aside from twisted.plugins, I wasn't aware of anybody in Python
doing that... and as I described, I never really interpreted that
through the lens of "namespace package" vs. "plugin finding".
Right now it just says that it's a package which resides in multiple
directories, and it's not made clear why that's a desirable feature.
Good point; perhaps you can suggest some wording on these matters to Martin?
Okay. So what I'm hearing is that Twisted should happily continue
using our own wacky __path__-calculation logic for twisted.plugins,
but that *twisted* should be a namespace package so that our
separate distributions (TwistedCore, TwistedWeb, TwistedConch, et.
al.) can be installed into separate directories.
Yes.
Thanks for taking the time to participate in this and add another
viewpoint to the mix, not to mention clarifying some areas where the
PEP could be clearer.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
