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