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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
