Simpler namespace packages

I was reading over PEP 382 and am not sure I really understand how it is a worthwhile step forward. Namespace packages are currently a mess and personally if anyone asks me I recommend not using the currently-available approach at all. Would it be possible to allow a more simple definition, for example putting the dot itself in the filename? Where these would be similar? site-packages/ foo/ __init__.py foo.bar.py foo.baz/ __init__.py qux.py foo.spam.eggs.py and site-packages/ foo/ __init__.py bar.py baz/ __init__.py qux.py spam/ __init__.py #empty eggs.py Obviously this is not fully-defined, but would this kind of approach fill the same need and be nicer to use, create, find, and understand then what is proposed in PEP 382?

On Mon, Jun 20, 2011 at 10:03 AM, Mike Graham <mikegraham@gmail.com> wrote:
I fail to see how the first example is clearer than the second. Indeed the opposite seems to be true. What i think you need to understand is that the name of the module is the same as the path to it. IMO the current system emphasizes that very strongly and this proposal would only make the concept less clear. --Alex

On Mon, Jun 20, 2011 at 10:26 AM, Alex Light <scialexlight@gmail.com> wrote:
The first example ISN'T clearer than the second. I think the second is more easily understood to be sure. The first example, I'm saying, may be clearer than other implementations of namespace packages, not clearer than a normal package. A namespace package is one where the top level(s) aren't for a normal package. If foo.bar and foo.baz and foo.qux were distributed completely separately, foo would be a namespace package. Currently, a namespace package might look like site-packages/ foo/ # No __init__.py in foo bar/ __init__.py spam.py foo.bar-1.2.3-py2.7-nspkg.pth # A pth file to tell Python how to import the package foo.bar-1.2.3-py2.7.egg-info/ namespace_packages.txt # This would say "foo" in it ....other stuff and PEP382 tries to improve the situation a bit. I'm hoping we can come up with something that is easily understood. Mike

On Mon, Jun 20, 2011 at 10:03 AM, Mike Graham <mikegraham@gmail.com> wrote:
I fail to see how the first example is clearer than the second. Indeed the opposite seems to be true. What i think you need to understand is that the name of the module is the same as the path to it. IMO the current system emphasizes that very strongly and this proposal would only make the concept less clear. --Alex

On Mon, Jun 20, 2011 at 10:26 AM, Alex Light <scialexlight@gmail.com> wrote:
The first example ISN'T clearer than the second. I think the second is more easily understood to be sure. The first example, I'm saying, may be clearer than other implementations of namespace packages, not clearer than a normal package. A namespace package is one where the top level(s) aren't for a normal package. If foo.bar and foo.baz and foo.qux were distributed completely separately, foo would be a namespace package. Currently, a namespace package might look like site-packages/ foo/ # No __init__.py in foo bar/ __init__.py spam.py foo.bar-1.2.3-py2.7-nspkg.pth # A pth file to tell Python how to import the package foo.bar-1.2.3-py2.7.egg-info/ namespace_packages.txt # This would say "foo" in it ....other stuff and PEP382 tries to improve the situation a bit. I'm hoping we can come up with something that is easily understood. Mike
participants (2)
-
Alex Light
-
Mike Graham