<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, 27 Jan 2016 at 08:49 Andrew Barnert via Python-ideas <<a href="mailto:python-ideas@python.org">python-ideas@python.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Jan 27, 2016, at 07:39, Victor Stinner <<a href="mailto:victor.stinner@gmail.com" target="_blank">victor.stinner@gmail.com</a>> wrote:<br>
><br>
> Hi,<br>
><br>
> Thank you for all feedback on my PEP 511. It looks like the current<br>
> blocker point is the unclear status of "language extensions": code<br>
> tranformers which deliberately changes the Python semantics. I would<br>
> like to discuss how we should register them. I think that the PEP 511<br>
> must discuss "language extensions" even if it doesn't have to propose<br>
> a solution to make their usage easier. It's an obvious usage of code<br>
> transformers. If possible, I would like to find a compromise to<br>
> support them, but make it explicit that they change the Python<br>
> semantics.<br>
<br>
Is this really necessary?<br>
<br>
If someone is testing a language change locally, and just wants to use your (original) API for his tests instead of the more complicated alternative of building an import hook, it works fine. If he can't deploy that way, that's fine.<br>
<br>
If someone builds a transformer that adds a feature in a way that makes it a pure superset of Python, he should be fine with running it on all files, so your API works fine. And if some files that didn't use any of the new features get .pyc files that imply they did, so what?<br>
<br>
If someone builds a transformer that only runs on files with a different extension, he already needs an import hook, so he might as well just call his transformer from the input hook, same as he does today.<br></blockquote><div><br></div><div>And the import hook is not that difficult. You can reuse everything from importlib without modification except for needing to override a single method in some loader to do your transformation (<a href="https://docs.python.org/3/library/importlib.html#importlib.abc.InspectLoader.source_to_code">https://docs.python.org/3/library/importlib.html#importlib.abc.InspectLoader.source_to_code</a>). Otherwise the only complication is instantiating the right classes and setting the path hook in `sys.path_hooks`.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
So... What case is served by this new, more complicated API that wasn't already served by your original, simple one (remembering that import hooks are already there as a fallback)?<br></blockquote><div><br></div><div>As Victor pointed out, the discussion could end in "nothing changed, but we at least discussed it". I think both you and I currently agree that's the answer to his question. :)</div><div><br></div><div>-Brett</div></div></div>