[Import-SIG] Proposed design for importlib.resources()

[Brett Cannon]

On Fri, 20 Nov 2015 at 20:01 Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 21 November 2015 at 07:23, Brett Cannon <brett at python.org> wrote:
>
>> 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
>> http://nbviewer.jupyter.org/gist/brettcannon/9c4681a77a7fa09c5347 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:
>> https://www.continuum.io/downloads; I have filed
>> https://github.com/binder-project/binder/issues/38 to try and get
>> mybinder.org updated to Python 3.5 so that can be used instead).
>>
>> 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.
>>
>
> 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,
>

Dammit, it was so convenient!


> "resource_reader" either needs to be a new optional attribute on the
> module spec, or else a new optional method on the Loader API.
>

Yep.


>
> 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.
>

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).


>
> Some other smaller notes:
>
> * 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).
>

Typo fixed in my copy.


> * 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:
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx
> * There's also an open issue discussing the significant limitations of
> tempfile.NamedTemporaryFile on Windows: http://bugs.python.org/issue14243
>
> 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.
>

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.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/import-sig/attachments/20151121/66434749/attachment-0001.html>