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

[Brett Cannon]

On Sun, Jul 10, 2011 at 20:10, P.J. Eby <pje at telecommunity.com> wrote:

> 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<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.
>

I didn't read the thread, but I don't get the worry here. A 'time' package
already will shadow a 'time' module if it is farther up sys.path, so this
proposal in any of its current forms won't change that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/import-sig/attachments/20110710/3b8b7157/attachment-0001.html>