On Sat, Jan 16, 2016 at 12:22 PM, Sjoerd Job Postmus <sjoerdjob@sjec.nl> wrote:

>
> or making it easier to write an import hook with them, etc...

So, you'd have to supply the transformer used before importing? That
seems like a troublesome solution to me.

A better approach (to me) would require being able to document what
transformers need to be run inside the module itself. Something like

#:Transformers modname.TransformerClassName, modname.OtherTransformerClassName

The reason why I would prefer this, is that it makes sense to document
the transformers needed in the module itself, instead of in the code
importing the module.

+1 for this (but see below). This is the approach I used when playing with import hooks as shown in

http://aroberge.blogspot.ca/2015/10/from-experimental-import-somethingnew_14.html

and a few other posts I wrote about similar transformations.

As you suggest (and rightly so) to localize the effects of the
registration, it makes sense to do the registration in the affected
module.

Of course there might be some cases where you want to import a module
using a transformer it does not need to know about, but I think that
would be less likely than the case where a module knows what
transformers there should be applied.

As an added bonus, it would let you apply transformers to the
entry-point:

#!/usr/bin/env python
#:Transformers foo.BarTransformerMyCodeCanNotRunWithout

But as you said, this support is probably outside the scope of the PEP
anyway.

While I would like to see some standard way to apply code transformations, I agree that this is likely (and unfortunately) outside the scope of this PEP.

André Roberge

Kind regards,
Sjoerd Job
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/