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

Chris Angelico rosuav at gmail.com
Fri Sep 2 18:50:37 EDT 2016

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 coextra 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

More information about the Python-Dev mailing list