On Jan 29, 2016, at 06:10, Nick Coghlan <ncoghlan@gmail.com> wrote:
>
> PEP 511 erases that piece of incidental complexity and say, "If you
> want to apply a genuinely global transformation, this is how you do
> it". The fact we already have decorators and import hooks is why I
> think PEP 511 can safely ignore the use cases that those handle.

I think this is the conclusion I was hoping to reach, but wasn't sure how to get there. I'm happy with PEP 511 not trying to serve cases like MacroPy and Hy and the example from the byteplay docs, especially so if ignoring them makes PEP 511 simpler, as long as it can explain why it's ignoring them. And a shorter version of your argument should serve as such an explanation.

But the other half of my point was that too many people (even very experienced developers like most of the people on this list) think there's more incidental complexity than there is, and that's also a problem. For example, "I want to write a global processor for local experimentation purposes so I can play with my idea before posting it to Python-ideas" is not a bad desire. And, if people think it's way too hard to do with a quick&dirty import hook, they're naturally going to ask why PEP 511 doesn't help them out by adding a bunch of options to install/run the processors conditionally, handle non-.py files, skip the stdlib, etc. And I think the PEP is better without those options.

> However, I think it *would* make sense to make the creation of a "Code
> Transformation" HOWTO guide part of the PEP - having a guide means we
> can clearly present the hierarchy in terms of:

I like this idea.

Earlier I suggested that the import system documentation should have some simple examples of how to actually use the import system to write transforming hooks. Someone (Brett?) pointed out that it's a dangerous technique, and making it too easy for people to play with it without understanding it may be a bad idea. And they're probably right.

A HOWTO is a bit more "out-of-the-way" than library or reference docs--and, more importantly, it also has room to explain when you shouldn't do this or that, and why.

I'm not sure it has to be part of the PEP, but I can see the connection. While the PEP helps by separating out the most important safe case (semantically-neutral, reflected in .pyc, globally consistent, etc.), but it also makes the question "how do I do something similar to PEP 511 transformers except ___" more likely to come up in the first place, making the HOWTO more important.

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