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

[Nick Coghlan]

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 - using
monkeypatching for use cases like testing and monitoring means those
cases can be ignored when reading and writing the code, using
metaclasses lets you enlist the interpreter in defining "class-like"
objects that differ in some specific way from normal ones (e.g. ORMs,
ABCs, enums), using codecs lets you more easily provide configurable
encoding and decoding behaviour, etc.

While relying too heavily on those kinds of features can significantly
harm debuggability, the pay-off in readability is worth it often
enough for them to be officially supported language and runtime
features.

The kind of code transformation hooks that Victor is talking about
here are the ultimate in action at a distance - if it wants to, an
"optimizer" can completely throw away your code and substitute its
own. Import hooks do indeed give you a comparable level of power (at
least if you go so far as to write your own meta_path hook), but also
still miss the code that Python runs without importing it (__main__,
exec, eval, runpy, etc).

> even if people only want one of them served (normally, Python doesn't go out of its way to prevent writing certain kinds of code, it just becomes accepted that such code is not idiomatic; only when there's a real danger of attractive nuisance is the language modified to ban it), and I think it's potentially a positive.

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.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia