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

[Nick Coghlan]

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,
"resource_reader" either needs to be a new optional attribute on the module
spec, or else a new optional method on the Loader API.

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.

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

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/import-sig/attachments/20151121/957f687e/attachment.html>