From ericsnowcurrently at gmail.com Wed Sep 14 20:34:13 2016 From: ericsnowcurrently at gmail.com (Eric Snow) Date: Wed, 14 Sep 2016 18:34:13 -0600 Subject: [Import-SIG] ImportState vs. ImportSystem Message-ID: 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. -eric From ncoghlan at gmail.com Thu Sep 15 02:18:10 2016 From: ncoghlan at gmail.com (Nick Coghlan) Date: Thu, 15 Sep 2016 16:18:10 +1000 Subject: [Import-SIG] ImportState vs. ImportSystem In-Reply-To: References: Message-ID: On 15 September 2016 at 10:34, Eric Snow 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 | ncoghlan at gmail.com | Brisbane, Australia