[Python-ideas] PEP 511: API for code transformers

[Andrew Barnert]

On Jan 16, 2016, at 22:06, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
>> On 17 January 2016 at 14:28, Andrew Barnert <abarnert at yahoo.com> wrote:
>> So, I'm still not convinced that the distinction really is critical here. I definitely don't see why it's a negative that the PEP can serve both purposes,
> 
> The main problem with globally enabled transformations of any kind is
> that action at a distance in software design is generally a *bad
> thing*. Python's tolerant of it because sometimes it's a *necessary*
> thing that actually makes code more maintainable

...

> That's all I'm suggesting - I think the proposed hooks should be
> designed for globally enabled optimizations (and named accordingly),
> but I don't think we should erect any specific barriers against using
> them for other things. Designing them that way will provide a healthy
> nudge towards the primary intended use case (transparently enabling
> semantically compatible code optimizations), while still providing a
> new transformation technique to projects like MacroPy.

OK, then I agree 100% on this part.

But on the main point, I still think it's important for the PEP to explain why import hooks aren't good enough for semantically-neutral global optimizations. As I said, I can think of multiple answers (top-level code, interaction with .pyc files,
etc.), but as long as the PEP doesn't give those answers, people are going to keep asking (even years from now, when people want to know why TOOWTDI didn't apply here).