<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 24, 2019 at 4:28 PM Yuya Nishihara <<a href="mailto:yuya@tcha.org">yuya@tcha.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, 23 Apr 2019 23:37:17 -0400, Ludovic Chabant wrote:<br>
> > Does find_module() return a spec? We might instead have to skip py3.4<br>
> > finders.<br>
> <br>
> Ah you're right, it returns something else. It looks like Python<br>
> does this:<br>
> <br>
>     try:<br>
>         find_spec = finder.find_spec<br>
>     except AttributeError:<br>
>         loader = finder.find_module(name)<br>
>         if loader is None:<br>
>             return None<br>
>         return importlib.util.spec_from_loader(name, loader)<br>
>     else:<br>
>         return find_spec(name)<br>
> <br>
> We can either emulate the same logic, or just skip old finders?<br>
<br>
No idea. Do we have to support unknown finders?<br></blockquote><div><br></div><div>We don't *need* to support unknown finders. But if we ignore them, we run the risk that they are provided functionality necessary for running Mercurial. e.g. a zip import finder may be necessary to find the Mercurial source/bytecode data. This is the problem with the source transforming module importer: it only works if things are reasonably "normal."</div><div><br></div><div>Since we want to remove the source transforming module importer, I'm fine doing something less than ideal for now in the name of furthering Python 3 support faster. Hopefully all this code is deleted before Python 3 support is stable and we won't have anything to worry about.<br></div></div></div>