[Import-SIG] New PEP Draft: Import Engine

[Nick Coghlan]

On Mon, Aug 1, 2011 at 12:51 AM, P.J. Eby <pje at telecommunity.com> wrote:
> It would be much better if you can reframe your proposal in terms of
> *additions* to the PEP 302 protocol, rather than *changes*.

They really are additions, just in the form of an optional argument
rather than new methods.

The idea is that the builtin import would continue to call the PEP 302
methods according to their current signature, so existing
implementations of importers and loaders would continue to work
without modification. Engine-based importers and loaders would use the
idiom described in the PEP in order to support both styles of access -
if the engine argument is missing, they take that as "ah, this is a
process global import" and fall back on the global engine instance
that uses property descriptors to access the existing process global
state.

The GlobalImportState subclass will similarly omit the engine argument
when invoking the PEP 302 APIs.

Aside from that, the incompatibilities and changes in assumptions run
too deep - old style importers would *only* be usable with the global
import state (including via the GlobalImportState API). However, all
of the importlib importers and loaders would be updated to support the
engine argument.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia