[Import-SIG] What if namespace imports weren't special?

[P.J. Eby]

At 10:34 PM 7/10/2011 -0400, P.J. Eby wrote:
>The big advantage of this approach is that it doesn't require us to 
>have a special name - it's just, "Enhanced Package Imports" or some 
>such.  No special marker files to name, either.  Just, "hey, people 
>want to put their package contents in more than one directory, and 
>they don't always need an __init__.py."
>
>Thoughts, anyone?

A quick follow-up; I found a thread where something vaguely similar 
was discussed before:

   http://mail.python.org/pipermail/python-dev/2006-April/064400.html

Various issues regarding tool support were brought up, mainly that 
existing tools would not detect such packages as packages, and that 
doing this at the top level was problematic because of the 
possibility of blocking a module like 'string' or 'time' or some such.

However, as it happens, with a slight adjustment to what I proposed, 
that latter issue can be addressed...  if *any* loadable module 
anywhere on sys.path (vs. just a directory with an __init__) simply 
gets all the subpaths appended to its __path__, then having a "time" 
directory just gets it added to time.__path__ -- and the plain old 
__time__ module still gets loaded.

Tool support isn't actually as much affected by my revised approach 
either, since if you don't intend a directory to be a package, you're 
not importing it.  If you have a directory and your tool *doesn't* 
recognize it as a package, well, that's an issue of the tool adding 
support for namespace packages.  Likewise, if you have a module or 
package that's working today, all that happens is that it grows a 
__path__ and has sub-imports possible.

It does seem that the previous discussion was rather controversial, 
even though only sub-packages were being discussed.  OTOH, the change 
really *was* a change, and my proposal doesn't change the existing 
behavior (apart from some occasional __path__ attributes appearing 
where they didn't before), it only adds to it.