[Python-ideas] PEP 511: Add a check function to decide if a "language extension" code transformer should be used or not

[Brett Cannon]

On Wed, 27 Jan 2016 at 08:49 Andrew Barnert via Python-ideas <
python-ideas at python.org> wrote:

> On Jan 27, 2016, at 07:39, Victor Stinner <victor.stinner at gmail.com>
> wrote:
> >
> > Hi,
> >
> > Thank you for all feedback on my PEP 511. It looks like the current
> > blocker point is the unclear status of "language extensions": code
> > tranformers which deliberately changes the Python semantics. I would
> > like to discuss how we should register them. I think that the PEP 511
> > must discuss "language extensions" even if it doesn't have to propose
> > a solution to make their usage easier. It's an obvious usage of code
> > transformers. If possible, I would like to find a compromise to
> > support them, but make it explicit that they change the Python
> > semantics.
>
> Is this really necessary?
>
> 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.
>
> 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?
>
> 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.
>

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 (
https://docs.python.org/3/library/importlib.html#importlib.abc.InspectLoader.source_to_code).
Otherwise the only complication is instantiating the right classes and
setting the path hook in `sys.path_hooks`.


>
> 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)?
>

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

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160127/9d478ab3/attachment.html>