At 09:49 PM 7/10/2011 -0700, Brett Cannon wrote: . 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: 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.