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.