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... 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/