[Import-SIG] What if namespace imports weren't special?
brett at python.org
Mon Jul 11 06:51:13 CEST 2011
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
>> Thoughts, anyone?
> 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
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...
More information about the Import-SIG