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

["Martin v. Löwis"]

Am 24.06.2011 18:29, schrieb P.J. Eby:
> Do we really need to read .pth files in PEP 382?  If so, why?

"Do we really need?" - of course not; life goes on even without
Python at all. "Are there use cases for it?" I think so.

I think the same question can be asked about .pth files in the
first place: "do we really need them"? Certainly not; people could
have done everything they do even without .pth files.

In any case, the motivation for using .pth files in PEP 382
was that I considered a natural extension to the mechanism that
was already there.

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.

> If we separate the "this is a namespace" funtionality from "here are
> paths" functionality, ISTM that the "here are paths" functionality is
> already adequately met by the existing .pth machinery.

I agree that it would simplify the PEP to not have to look into the
contents of a .pth file. Before discussing what the implementation
would look like exactly, I'd rather first establish whether there
is agreement to drop the feature.

So: anybody opposed to not being able to specify the path of a package
in a declarative manner?

Regards,
Martin

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