Re: ImportState vs. ImportSystem
Nick Coghlan <[email protected]> Thu, 15 Sep 2016 16:18:10 +1000
| Newsgroups | gmane.comp.python.import |
|---|---|
| Message-ID | <CADiSq7eNoeQQN5gUsdcOx6L3V0ZokdWw=Bzqw+ANcq4ToDCTMQ@mail.gmail.com> |
On 15 September 2016 at 10:34, Eric Snow <[email protected]> wrote: > 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 think distinct is a good way to go, as that lets you tackle the problem in multiple refactoring and design steps: 1. Encapsulate the existing import state as a private shim that accesses the `sys` module and use that shim in the existing import machinery 2. Based on your experience in (1), design a mechanism to more easily swap out the entire import system with a different one The reason I suggest that is because PEP 406 mainly foundered on the problem of maintaining compatibility with existing import system plugins, and pursuing step 1 should give you a better handle on the exact scope of that challenge and possible resolutions to it (e.g. a decimal or asyncio style thread-local context). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia