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

[Chris Angelico]

On Sun, Sep 4, 2016 at 2:09 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 3 September 2016 at 08:50, Chris Angelico <rosuav at gmail.com> wrote:
>> Got it, thanks. I hope the vagaries of linear search don't mess with
>> profilers - a debugger isn't going to be bothered by whether it gets
>> first slot or second, but profiling and performance might get subtle
>> differences based on which thing looks at a function first. A dict
>> would avoid that (constant-time lookups with a pre-selected key will
>> be consistent), but costs a lot more.
>
> Profiling with a debugger enabled is going to see a lot more
> interference from the debugger than it is from a linear search through
> a small tuple for its own state :)

Right; I was contrasting the debugger at one end (linear search is
utterly dwarfed by other costs) with a profiler at the other end
(wants minimal cost, and minimal noise, and a linear search gives cost
and noise). In between, an optimizer is an example of something that
could mess with the profiler based on activation ordering (and thus
which one gets first slot).

> Optimising compilers and VM profilers are clearly a case where
> cooperation will be desirable, as are optimising compilers and
> debuggers. However, that cooperation is still going to need to be
> worked out on a pairwise basis - the PEP can't magically make
> arbitrary pairs of plugins compatible, all it can do is define some
> rules and guidelines that make it easier for plugins to cooperate when
> they want to do so.

Obviously, but AIUI the rules sound pretty simple:

1) Base compiler: co_extra = ()
2) Modifier: co_extra += (MyState(),)
3) Repeat #2 for other tools
4) for obj in co_extra: if obj.__class__ is MyState: do stuff

Anyone who puts a non-tuple into co_extra is playing badly with other
people. Anyone who doesn't use a custom class is risking collisions.
Beyond that, it should be pretty straight-forward.

ChrisA