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

[P.J. Eby]

At 09:49 PM 7/10/2011 -0700, Brett Cannon wrote:
>I prefer going with a specifically named file if for any other 
>reason than there will be less broken tools. By shifting everything 
>into a subdirectory you prevent any pre-existing code that scans 
>sys.path from doing anything. But with the special file approach you 
>don't break those tools in the case of when you didn't have some 
>package fragment farther down sys.path.

I'm not sure I follow you.  The approach we're explicitly 
recommending for new namespaces is to *not* use an __init__, so the 
tools will still fail unless they're updated.

What you're saying is that in some cases, these tools will 
accidentally *seem* to work under the flag-file proposal, but will 
only see the contents of the first portion on sys.path.  IOW, I don't 
think that you can claim that tools won't be broken by a flag file 
approach, or even that they'll really be *less* broken than by a 
subdirectory approach.

(Also, if tools are using pkgutil's module traversal API, they won't 
have a problem, as it will be updated to match the import semantics 
-- and this should provide tool authors an incentive to start using 
that API, if they're not already doing so.)


>  Plus you can also use a specially named file instead of allowing 
> for any file name with a specific file ending to achieve the same 
> result (e.g., py.pkg or __init__.part).

I'm not quite following you here; it sounds like you're talking about 
a single fixed filename, which won't work for the reasons described 
in the "rejected alternatives" section at the end of this draft:

    http://mail.python.org/pipermail/import-sig/2011-July/000213.html

That draft proposed "DistributionName.ns" as the flag file naming 
pattern, and recent discussion has proposed .pypart or .pyp as 
alternate extensions.

The present thread ("what if namespaces aren't special?") is an 
experiment to see if we could find a way to dispense with flag files 
altogether, thereby simplifying the terminology and usage, as well as 
saving us a listdir call or two.