I've had some offline discussion with Brett and Nick about PEP 451
">

(original) (raw)



On Thu, Oct 24, 2013 at 2:05 AM, Eric Snow <ericsnowcurrently@gmail.com> wrote:
I've had some offline discussion with Brett and Nick about PEP 451

which has led to some meaningful clarifications in the PEP. In the

interest of pulling further discussions back onto this

(archived/public) list, here's an update of what we'd discussed and

where things are at. :)



* path entry finders indicate that they found part of a possible

namespace package by returning a spec with no loader set (but with

submodule_search_locations set). Brett wanted some clarification on

this.

* The name/path signature and attributes of file-based finders in

importlib will no longer be changing. Brett had some suggestions on

the proposed change and it became clear that the the change was

actually pointless.

* I've asserted that there shouldn't be much difficulty in adjusting

pkgutil and other modules to work with ModuleSpec.

* Brett asked for clarification on whether the "load()" example from

the PEP would be realized implicitly by the import machinery or

explicitly as a method on ModuleSpec. This has bearing on the ability

of finders to return instances of ModuleSpec subclasses or even

ModuleSpec-like objects (a la duck typing). The answer is the it will

not be a method on ModuleSpec, so it is effectively just part of the

general import system implementation. Finders may return any object

that provides the attributes of ModuleSpec. I will be updating the

PEP to make these points clear.



* Nick suggested writing a draft patch for the language reference

changes (the import page). Such a patch will be a pretty good

indicator of the impact of PEP 451 on the import system and should

highlight any design flaws in the API. This is on my to-do list

(hopefully by tomorrow).


Eric's got an initial patch for this up on http://bugs.python.org/issue18864 .

* Nick also suggested moving all ModuleSpec methods to a separate

class that will simply make use of a separate, existing ModuleSpec

instance. This will help address several issues, particularly by

relaxing the constraints on what finders can return, but also by

avoiding the unnecessary exposure of the methods via every

module.__spec__. I plan on going with this, but currently am trying

out the change to see if there are any problems I've missed. Once I

feel good about it I'll update the PEP.



That about sums up our discussions. I have a couple of outstanding

updates to the PEP to make when I get a chance, as well as putting up

a language reference patch for review.


After reading Eric's doc patch, I realized there is one change I want to make to the current semantics and that's not to backfill __package__ when set to None. Since import is now going to take over the job of setting __package__ (along with other attributes), this seems like a slight waste of effort. It also kills (or at least complicates) having a loader which does lazy loading since reading the attribute to see if it is None would trigger the load before leaving the import code, thus killing any postponed loading.