[Python-Dev] PEP 420 - dynamic path computation is missing rationale

[Eric V. Smith]

On 5/20/2012 9:33 PM, Guido van Rossum wrote:
> Generally speaking the PEP is a beacon if clarity. But I stumbled
> about one feature that bothers me in its specification and through its
> lack of rationale. This is the section on Dynamic Path Computation:
> (http://www.python.org/dev/peps/pep-0420/#dynamic-path-computation).
> The specification bothers me because it requires in-place modification
> of sys.path. Does this mean sys.path is no longer a plain list? I'm
> sure it's going to break things left and right (or at least things
> will be violating this requirement left and right); there has never
> been a similar requirement (unlike, e.g., sys.modules, which is
> relatively well-known for being cached in a C-level global variable).
> Worse, this apparently affects __path__ variables of namespace
> packages as well, which are now specified as an unspecified read-only
> iterable. (I can only guess that there is a connection between these
> two features -- the PEP doesn't mention one.) Again, I would be much
> happier with just a list.

sys.path would still be a plain list. It's the namespace package's
__path__ that would be a special object. Every time __path__ is accessed
it checks to see if it's parent path has been modified. The parent path
for top level modules is sys.path. The __path__ object detects
modification by keeping a local copy of the parent, plus a reference to
the parent, and compares them.

> While I can imagine there being a use case for recomputing the various
> paths, I am much less sure that it is worth attempting to specify that
> this will happen *automatically* when sys.path is modified in a
> certain way. I'd be much happier if these constraints were struck and
> the recomputation had to be requested explicitly by calling some new
> function in sys.
> 
>>From my POV, this is the only show-stopper for acceptance of PEP 420.
> (That is, either a rock-solid rationale should be supplied, or the
> constraints should be removed.)

I don't have a preference on whether the feature stays or goes, so I'll
let PJE give the use case. I've copied him here in case he doesn't read
python-dev.

Now that I think about it some more, the motivation is probably to ease
the migration from setuptools, which does provide this feature.

Eric.