Re: Proposed design for importlib.resources()

--===============4619465308252426265==
Content-Type: multipart/alternative; boundary=001a11428c924160ed0525050bd0

--001a11428c924160ed0525050bd0
Content-Type: text/plain; charset=UTF-8

On 21 November 2015 at 07:23, Brett Cannon <[email protected]> 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   |   [email protected]   |   Brisbane, Australia

--001a11428c924160ed0525050bd0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 2=
1 November 2015 at 07:23, Brett Cannon <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:[email protected]" target=3D"_blank">[email protected]</a>&gt;</span> wro=
te:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;=
border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">I=
 have created a Jupyter Notebook to explain my thinking on what importlib.r=
esources() should be (at least initially). You can view the notebook at=C2=
=A0<a href=3D"http://nbviewer.jupyter.org/gist/brettcannon/9c4681a77a7fa09c=
5347" target=3D"_blank">http://nbviewer.jupyter.org/gist/brettcannon/9c4681=
a77a7fa09c5347</a>=C2=A0or download it and play with the code live in your =
own copy (you can download Anaconda 2.4 if you don&#39;t have Jupyter alrea=
dy set up under Python 3.5:=C2=A0<a href=3D"https://www.continuum.io/downlo=
ads" target=3D"_blank">https://www.continuum.io/downloads</a>; I have filed=
=C2=A0<a href=3D"https://github.com/binder-project/binder/issues/38" target=
=3D"_blank">https://github.com/binder-project/binder/issues/38</a>=C2=A0to =
try and get <a href=3D"http://mybinder.org" target=3D"_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&#39=
;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>The general usage API design looks good to me, but the =
current proposal for retrieving the resource reader uses loader_state incor=
rectly - that&#39;s defined in PEP 451 as an opaque=20
object from the import machinery&#39;s point of view, so there&#39;s no=20
requirement for it to be a mapping. Instead, &quot;resource_reader&quot; ei=
ther=20
needs to be a new optional attribute on the module spec, or else a new=20
optional method on the Loader API.<br><br>My preference is for the latter, =
as=20
that way we&#39;ll never create resource reader instances for the vast=20
majority of modules, while with the current proposal we&#39;d create a=20
reader instance for every module *spec* constructed, even if nothing in the=
 application=20
uses the new resource access API.<br><br></div><div>Some other smaller note=
s:<br></div><div><br></div><div class=3D"gmail_extra">* The notebook report=
s the result of your straw poll incorrectly - you say &quot;approach 2&quot=
; won out, but &quot;approach 1&quot; (the object oriented one) did (by a 4=
:1 margin).<br>* In relation to sharing files, there are actually options w=
e can pass to CreateFile to make it possible to open a temporary file by na=
me even while we keep the original handle open: <a href=3D"https://msdn.mic=
rosoft.com/en-us/library/windows/desktop/aa363858%28v=3Dvs.85%29.aspx">http=
s://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=3Dvs.85%2=
9.aspx</a><br>* There&#39;s also an open issue discussing the significant l=
imitations of tempfile.NamedTemporaryFile on Windows: <a href=3D"http://bug=
s.python.org/issue14243">http://bugs.python.org/issue14243</a><br><br></div=
><div class=3D"gmail_extra">I don&#39;t think either of those notes about s=
hared file access on Windows affect your proposed solution, I just think th=
ey&#39;re worth referencing.<br></div></div></div><div class=3D"gmail_extra=
"><br></div><div class=3D"gmail_extra">Cheers,<br></div><div class=3D"gmail=
_extra">Nick.<br></div><div class=3D"gmail_extra"><br></div><div class=3D"g=
mail_extra">-- <br><div class=3D"gmail_signature">Nick Coghlan=C2=A0=C2=A0 =
|=C2=A0=C2=A0 <a href=3D"mailto:[email protected]" target=3D"_blank">ncogh=
[email protected]</a>=C2=A0=C2=A0 |=C2=A0=C2=A0 Brisbane, Australia</div>
</div></div>

--001a11428c924160ed0525050bd0--

--===============4619465308252426265==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Import-SIG mailing list
[email protected]
https://mail.python.org/mailman/listinfo/import-sig

--===============4619465308252426265==--