[Import-SIG] What if namespace imports weren't special?
pje at telecommunity.com
Mon Jul 11 05:10:09 CEST 2011
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."
A quick follow-up; I found a thread where something vaguely similar
was discussed before:
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.
More information about the Import-SIG