<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, 20 Nov 2015 at 20:01 Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 21 November 2015 at 07:23, Brett Cannon <span dir="ltr"><<a href="mailto:brett@python.org" target="_blank">brett@python.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I have created a Jupyter Notebook to explain my thinking on what importlib.resources() should be (at least initially). You can view the notebook at <a href="http://nbviewer.jupyter.org/gist/brettcannon/9c4681a77a7fa09c5347" target="_blank">http://nbviewer.jupyter.org/gist/brettcannon/9c4681a77a7fa09c5347</a> or download it and play with the code live in your own copy (you can download Anaconda 2.4 if you don't have Jupyter already set up under Python 3.5: <a href="https://www.continuum.io/downloads" target="_blank">https://www.continuum.io/downloads</a>; I have filed <a href="https://github.com/binder-project/binder/issues/38" target="_blank">https://github.com/binder-project/binder/issues/38</a> to try and get <a href="http://mybinder.org" target="_blank">mybinder.org</a> updated to Python 3.5 so that can be used instead).<div><br></div><div>The notebook is a bit long and is much better formatted elsewhere, so I'm not going to inline it here. If you want to comment on the notebook just copy and paste the relevant part into your reply.</div></div></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>The general usage API design looks good to me, but the current proposal for retrieving the resource reader uses loader_state incorrectly - that's defined in PEP 451 as an opaque 
object from the import machinery's point of view, so there's no 
requirement for it to be a mapping. Instead,</div></div></div></div></blockquote><div><br></div><div>Dammit, it was so convenient!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> "resource_reader" either 
needs to be a new optional attribute on the module spec, or else a new 
optional method on the Loader API.<br></div></div></div></div></blockquote><div><br></div><div>Yep.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br>My preference is for the latter, as 
that way we'll never create resource reader instances for the vast 
majority of modules, while with the current proposal we'd create a 
reader instance for every module *spec* constructed, even if nothing in the application 
uses the new resource access API.<br></div></div></div></div></blockquote><div><br></div><div>I'll have to think about that. I'm not that worried about memory pressure from every module having a resource reader object (it's not like people import literally a million modules; I have never heard more than in the thousands). We could introduce Loader.resources(name) or __spec__.resources depending on how this plays out (people are welcome to provide feedback on which way they prefer).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Some other smaller notes:<br></div><div><br></div><div class="gmail_extra">* The notebook reports the result of your straw poll incorrectly - you say "approach 2" won out, but "approach 1" (the object oriented one) did (by a 4:1 margin).<br></div></div></div></div></blockquote><div><br></div><div>Typo fixed in my copy.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="gmail_extra">* In relation to sharing files, there are actually options we can pass to CreateFile to make it possible to open a temporary file by name even while we keep the original handle open: <a href="https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx" target="_blank">https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx</a><br>* There's also an open issue discussing the significant limitations of tempfile.NamedTemporaryFile on Windows: <a href="http://bugs.python.org/issue14243" target="_blank">http://bugs.python.org/issue14243</a><br><br></div><div class="gmail_extra">I don't think either of those notes about shared file access on Windows affect your proposed solution, I just think they're worth referencing.</div></div></div></div></blockquote><div><br></div><div>Yes, I'm ignoring everything you just said. :) If we were supporting the return of objects then I might care, but since I'm trying to keep the API surface small to start and thus not doing file objects this doesn't really play into this. If we add an open() method then these issues will be something we need to potentially care about.</div><div><br></div><div>-Brett </div></div></div>