[Python-Dev] Update on PEP 523 and adding a co_extra field to code objects (original) (raw)

Antoine Pitrou solipsis at pitrou.net
Tue Aug 30 12:07:29 EDT 2016

On Mon, 29 Aug 2016 21:38:19 +0000 Brett Cannon <brett at python.org> wrote:

For quick background for those that don't remember, part of PEP 523 proposed adding a coextra field to code objects along with making the frame evaluation function pluggable ( https://www.python.org/dev/peps/pep-0523/#expanding-pycodeobject). The idea was that things like JITs and debuggers could use the field as a scratch space of sorts to store data related to the code object. People who objected to the new field did either for memory ("it adds another pointer to the struct that won't be typically used"), or for conceptual reasons ("the code object is immutable and you're proposing a mutable field"). The latter is addressed by not exposing the field in Python and clearly stating that code should never expect the field to be filled.

Just a question: Maciej mentioned the field may be useful for vmprof. That's already two potential users (vmprof and Pyjion) for a single field. OTOH, the PEP says:

"""It is not recommended that multiple users attempt to use the co_extra simultaneously. While a dictionary could theoretically be set to the field and various users could use a key specific to the project, there is still the issue of key collisions as well as performance degradation from using a dictionary lookup on every frame evaluation. Users are expected to do a type check to make sure that the field has not been previously set by someone else."""

Does it mean that, in the event vmprof comes in and changes the field, Pyjion will have to recompile the function the next time it comes to execute it?

And, conversely, if Pyjion compiles a function while vmprof is enabled, vmprof will lose timing information (or whatever else, because I'm not sure what vmprof plans to store thre) for that code object?

Regards

Antoine.

More information about the Python-Dev mailing list