On 17 January 2016 at 21:48, Victor Stinner <victor.stinner@gmail.com> wrote:
2016-01-16 12:06 GMT+01:00 Petr Viktorin <encukou@gmail.com>:
The PEP is designed optimizers. It would be good to stick to that use case, at least as far as the registration is concerned. I suggest noting in the documentation that Python semantics *must* be preserved, and renaming the API, e.g.::
sys.set_global_optimizers([])
I would prefer to not restrict the PEP to a specific usage.
The problem I see with making the documentation and naming too generic is that people won't know what the feature is useful for - a generic term like "transformer" accurately describes these units of code, but provides no hint as to why a developer might care about their existence. However, if the reason we're adding the capability is to make global static optimizers feasible, then we cam describe it accordingly (so the answer to "Why does this feature exist?" becomes relatively self evident), and have the fact that the feature can actually be used for arbitrary transforms be an added bonus rather than the core intent. Alternatively, we could follow the example of the atexit module, and provide these hook registration capabilities through a new "atcompile" module rather than through the sys module. Doing that would also provide a namespace for doing things like allowing runtime caching of compiled code objects - if there's no caching mechanism, then optimising code compiled at runtime (rather than loading pre-optimised code from bytecode files) could easily turn into a pessimisation if the optimiser takes more time to run than is gained back in a single execution of the optimised code relative to the unoptimised code. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia