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

Nick Coghlan ncoghlan at gmail.com
Sun Jan 17 07:36:32 EST 2016


On 17 January 2016 at 21:48, Victor Stinner <victor.stinner at gmail.com> wrote:
> 2016-01-16 12:06 GMT+01:00 Petr Viktorin <encukou at 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 at gmail.com   |   Brisbane, Australia


More information about the Python-ideas mailing list