[Import-SIG] Do we really need to read .pth files in PEP 382?

[P.J. Eby]

At 07:48 PM 6/24/2011 +0200, Martin v. Löwis wrote:
>The use case I could imagine is what I think was the original use
>case for .pth files as well: allow users to contribute their own
>stuff to a package without having to modify a central location. The
>sysadmin could create a writable file /usr/lib/python.../zope/pje.pth,
>and you could then add stuff to the zope package without having write
>access to its package folder.

But as long as zope is flagged as a namespace package, those 
additions can be anywhere on sys.path (using an appropriate 
subdirectory structure), so having .pth file contents doesn't really 
add anything to this use case.

(Except the ability to have more-obscure directory names and to make 
it harder to find out where a module is being imported from, of 
course.  But I'm not sure that's really a feature. ;-) )


>P.S. FWIW, my approach to a checkmark for namespace-ness of a directory
>would be to have a directory name extension, say .ns or .py, indicating
>that this directory is a namespaced Python package - that would drop
>the need for special files at all (I actually think I'd prefer .py over
>.ns, despite the risk for confusion with Python source files).

The main reason I favor files over a directory name change is 
backward compatibility and ease of extension/upgrade.  With flag 
files, existing tools need only add a flag file to be conformant, and 
if they contain an __init__.py, then they are still compatible with 
older Pythons.

(And even if we did use a directory name, I think .py would introduce 
problems in existing code that globs for *.py files and tries to read them.)