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

[Chris Angelico]

On Sat, Sep 3, 2016 at 8:45 AM, Brett Cannon <brett at python.org> wrote:
>> I'm not following how this solves the collision problem. If you have a
>> tuple, how do the two (or more) users of it know which index they're
>> using? They'd need to keep track separately for each object, or else
>> inefficiently search the tuple for an object of appropriate type every
>> time. What am I missing here?
>
>
> You're not missing anything, you just have to pay for the search cost,
> otherwise we're back to square one here of not worrying about the case of
> multiple users. I don't see how you can have multiple users of a single
> struct field and yet not have to do some search of some data structure to
> find the relevant object you care about. We've tried maps and dicts and they
> were too slow, and we proposed not worrying about multiple users but people
> didn't like the idea of either not caring or relying on some implicit
> practice that  evolved around the co_extra field. Using a tuple seems to be
> the best option we can come up with short of developing a linked list which
> isn't that much better than a tuple if you're simply storing PyObjects. So
> either we're sticking with the lack of coordination as outlined in the PEP
> because you don't imagine people using a combination of Pyjion, vmprof,
> and/or some debugger simultaneously, or you do and we have to just eat the
> performance degradation.

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.

ChrisA