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:
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
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:
On Mon, Jun 20, 2011 at 10:03 AM, Mike Graham mikegraham@gmail.com wrote:
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
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
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
Sorry mixed up first and second examples
-alex On Jun 20, 2011 12:24 PM, "Mike Graham" mikegraham@gmail.com wrote:
On Mon, Jun 20, 2011 at 10:26 AM, Alex Light scialexlight@gmail.com
wrote:
On Mon, Jun 20, 2011 at 10:03 AM, Mike Graham mikegraham@gmail.com
wrote:
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
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
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
-
Alex Light -
Mike Graham