guido at python
May 21, 2012, 6:55 AM
On Mon, May 21, 2012 at 1:00 AM, Eric V. Smith <eric [at] trueblade> wrote:
Re: PEP 420 - dynamic path computation is missing rationale
[In reply to]
> 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:
>> 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.
Ah, I see. But I disagree that this is a reasonable constraint on
sys.path. The magic __path__ object of a toplevel namespace module
should know it is a toplevel module, and explicitly refetch sys.path
rather than just keeping around a copy.
This leaves the magic __path__ objects for namespace modules, which I
could live with, as long as their repr was not the same as a list, and
assuming a good rationale is given. Although I'd still prefer plain
lists here as well; I'd like to be able to manually construct a
namespace package and force its directories to be a specific set of
directories that I happen to know about, regardless of whether they
are related to sys.path or not. And I'd like to know that my setup in
that case would not be disturbed by changes to sys.path.
>> 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
> Now that I think about it some more, the motivation is probably to ease
> the migration from setuptools, which does provide this feature.
I'd like to hear more about this from Philip -- is that feature
actually widely used? What would a package have to do if the feature
didn't exist? I'd really much rather not have this feature, which
reeks of too much magic to me. (An area where Philip and I often
--Guido van Rossum (python.org/~guido)
Python-Dev mailing list
Python-Dev [at] python