Home Original page

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

MRAB python at mrabarnett.plus.com
Fri Sep 2 20:36:18 EDT 2016 
On 2016-09-02 23:45, Brett Cannon wrote:
>
>
> On Fri, 2 Sep 2016 at 15:11 Chris Angelico <rosuav at gmail.com
> <mailto:rosuav at gmail.com>> wrote:
>
>     On Sat, Sep 3, 2016 at 7:56 AM, Brett Cannon <brett at python.org
>     <mailto:brett at python.org>> wrote:
>     > On Fri, 2 Sep 2016 at 13:31 Dino Viehland via Python-Dev
>     > <python-dev at python.org <mailto:python-dev at python.org>> wrote:
>     >>
>     >> So it looks like both list and tuple are about within 5% of using
>     co_extra
>     >> directly.  Using a tuple instead of a list is about a wash except for
>     >> make_v2 where list is 1.4x slower for some reason (which I didn't
>     dig into).
>     >>
>     >> I would say that using a tuple and copying the tuple on updates makes
>     >> sense as we don't expect these to change very often and we don't
>     expect
>     >> collisions to happen very often.
>     >
>     >
>     > So would making co_extra a PyTupleObject instead of PyObject alleviate
>     > people's worry of a collision problem? You're going to have to
>     hold the GIL
>     > anyway to interact with the tuple so there won't be any race
>     condition in
>     > replacing the tuple when it's grown (or initially set).
>     >
>
>     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.
>
Could the users register themselves first? They could then be told what 
index to use.
More information about the Python-Dev mailing list