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

Guido van Rossum guido at python.org
Mon May 21 03:33:03 CEST 2012

I have just reviewed PEP 420 (namespace packages) and sent Eric my
detailed feedback; most of it is minor or requesting for examples and
I'm sure he'll fix it to my satisfaction.

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

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

--Guido van Rossum (python.org/~guido)

More information about the Python-Dev mailing list