[Import-SIG] ImportState vs. ImportSystem

Eric Snow ericsnowcurrently at gmail.com
Wed Sep 14 20:34:13 EDT 2016

I've been planning for a while to propose a successor to PEP 406
("Import Engine").  I've even prototyped several different approaches
over the years.  Last week got me thinking in earnest about it again.
So I wanted to run one question by the list.  However, I don't
necessarily want to dive into all the details of the full proposal
quite yet. :)

In a practical sense, encapsulation of the import state will be useful
on its own, particularly if it's easy to swap in and out (e.g. with/as
a context manager).  It is certainly the thing folks are most
interested in when I explain the proposal at a high level.  At the
same time, I consider having a richer model of the import system in
the stdlib to be an important objective.  Doing so makes the import
system more accessible by making it easier to understand (docs help
but concrete models, i.e. in importlib, make a big difference).

The question I'd like to focus on is: would it be better to have
separate ImportState and ImportSystem types, or have a single type
that fills both roles?  I'm leaning toward keeping them distinct since
the import machinery *uses* the state and state stands well on its
own.  Having a distinct ImportState type makes the functionality more
discoverable and more obvious.  Also, having distinct types helps
communicate the different layers at play, which invites discovery of
how the import system operates.

I'd love to hear what you think.


More information about the Import-SIG mailing list