Re: Proposal for a lazy-loading finder

--===============7155867850227708798==
Content-Type: multipart/alternative; boundary="001a1148d54ac41a280553fbe1dd"

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

On Mon, 10 Jul 2017 at 12:40 Eric Snow <[email protected]> wrote:

> On Sat, Jul 8, 2017 at 5:56 PM, Brett Cannon <[email protected]> wrote:
> > [snip]
> > I figured it was finally time to implement a lazy-loading finder
> > to make sure people don't duplicate the same work and to make sure that
> it
> > is implemented properly and can change as importlib itself does.
> > [snip]
> >
> > Please have a look at
> >
> https://notebooks.azure.com/Brett/libraries/di2Btqj7zSI/html/Lazy%20importing.ipynb
> > and let me know if I'm missing anything.
>
> LGTM.  It's good that the class mirrors FileFinder.
>
> The only things I'd possibly suggest are:
>
>  * name the class LazyLoadingFileFinder
>

This actually isn't restricted to FileFinder instances, it just so happens
that's the common case. The design is such that any finder will work where
the loader doesn't use a special object as the module instance, which is
most loaders.


>  * make activate_lazy_loading() be a classmethod on PathFinder
>

That's an idea since it is only tweaking stuff that PathFinder cares about.
It will hurt discoverability, though.


>
> Both make it clear that they only relate to path-entry finders.
>

False for the first, true for the second. :)


>
> I have some other concerns but they aren't problems with your
> proposal. :)  Mostly, I still want to see a better high-level
> interface to the import machinery (i.e. "ImportSystem").  Having to
> poke things directly into the import state (e.g. sys.path_hooks) isn't
> ideal.  However, I don't think my concerns are critical for this
> proposal so I won't elaborate here. :)
>

Beyond activate_lazy_loading() I don't think anything else would require
tweaking in an import system restructuring of import.

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

<div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon=
, 10 Jul 2017 at 12:40 Eric Snow &lt;<a href=3D"mailto:ericsnowcurrently@gm=
ail.com">[email protected]</a>&gt; wrote:<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">On Sat, Jul 8, 2017 at 5:56 PM, Brett Cannon &lt;<a href=
=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>&gt; wro=
te:<br>
&gt; [snip]<br>
&gt; I figured it was finally time to implement a lazy-loading finder<br>
&gt; to make sure people don&#39;t duplicate the same work and to make sure=
 that it<br>
&gt; is implemented properly and can change as importlib itself does.<br>
&gt; [snip]<br>
&gt;<br>
&gt; Please have a look at<br>
&gt; <a href=3D"https://notebooks.azure.com/Brett/libraries/di2Btqj7zSI/htm=
l/Lazy%20importing.ipynb" rel=3D"noreferrer" target=3D"_blank">https://note=
books.azure.com/Brett/libraries/di2Btqj7zSI/html/Lazy%20importing.ipynb</a>=
<br>
&gt; and let me know if I&#39;m missing anything.<br>
<br>
LGTM.=C2=A0 It&#39;s good that the class mirrors FileFinder.<br>
<br>
The only things I&#39;d possibly suggest are:<br>
<br>
=C2=A0* name the class LazyLoadingFileFinder<br></blockquote><div><br></div=
><div>This actually isn&#39;t restricted to FileFinder instances, it just s=
o happens that&#39;s the common case. The design is such that any finder wi=
ll work where the loader doesn&#39;t use a special object as the module ins=
tance, which is most loaders.<br></div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
=C2=A0* make activate_lazy_loading() be a classmethod on PathFinder<br></bl=
ockquote><div><br></div><div>That&#39;s an idea since it is only tweaking s=
tuff that PathFinder cares about. It will hurt discoverability, though.<br>=
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Both make it clear that they only relate to path-entry finders.<br></blockq=
uote><div><br></div><div>False for the first, true for the second. :)<br></=
div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I have some other concerns but they aren&#39;t problems with your<br>
proposal. :)=C2=A0 Mostly, I still want to see a better high-level<br>
interface to the import machinery (i.e. &quot;ImportSystem&quot;).=C2=A0 Ha=
ving to<br>
poke things directly into the import state (e.g. sys.path_hooks) isn&#39;t<=
br>
ideal.=C2=A0 However, I don&#39;t think my concerns are critical for this<b=
r>
proposal so I won&#39;t elaborate here. :)<br></blockquote><div><br></div><=
div>Beyond activate_lazy_loading() I don&#39;t think anything else would re=
quire tweaking in an import system restructuring of import.<br></div></div>=
</div>

--001a1148d54ac41a280553fbe1dd--

--===============7155867850227708798==
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

--===============7155867850227708798==--