On Thu, Oct 24, 2013 at 2:05 AM, Eric Snow <ericsnowcurren...@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.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
