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

[Antoine Pitrou]

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 co_extra 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.