On 17 January 2016 at 14:28, Andrew Barnert <abarnert@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@gmail.com | Brisbane, Australia