<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Fri, 2 Sep 2016 at 17:37 MRAB <<a href="mailto:python@mrabarnett.plus.com">python@mrabarnett.plus.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2016-09-02 23:45, Brett Cannon wrote:<br>
><br>
><br>
> On Fri, 2 Sep 2016 at 15:11 Chris Angelico <<a href="mailto:rosuav@gmail.com" target="_blank">rosuav@gmail.com</a><br>
> <mailto:<a href="mailto:rosuav@gmail.com" target="_blank">rosuav@gmail.com</a>>> wrote:<br>
><br>
>     On Sat, Sep 3, 2016 at 7:56 AM, Brett Cannon <<a href="mailto:brett@python.org" target="_blank">brett@python.org</a><br>
>     <mailto:<a href="mailto:brett@python.org" target="_blank">brett@python.org</a>>> wrote:<br>
>     > On Fri, 2 Sep 2016 at 13:31 Dino Viehland via Python-Dev<br>
>     > <<a href="mailto:python-dev@python.org" target="_blank">python-dev@python.org</a> <mailto:<a href="mailto:python-dev@python.org" target="_blank">python-dev@python.org</a>>> wrote:<br>
>     >><br>
>     >> So it looks like both list and tuple are about within 5% of using<br>
>     co_extra<br>
>     >> directly.  Using a tuple instead of a list is about a wash except for<br>
>     >> make_v2 where list is 1.4x slower for some reason (which I didn't<br>
>     dig into).<br>
>     >><br>
>     >> I would say that using a tuple and copying the tuple on updates makes<br>
>     >> sense as we don't expect these to change very often and we don't<br>
>     expect<br>
>     >> collisions to happen very often.<br>
>     ><br>
>     ><br>
>     > So would making co_extra a PyTupleObject instead of PyObject alleviate<br>
>     > people's worry of a collision problem? You're going to have to<br>
>     hold the GIL<br>
>     > anyway to interact with the tuple so there won't be any race<br>
>     condition in<br>
>     > replacing the tuple when it's grown (or initially set).<br>
>     ><br>
><br>
>     I'm not following how this solves the collision problem. If you have a<br>
>     tuple, how do the two (or more) users of it know which index they're<br>
>     using? They'd need to keep track separately for each object, or else<br>
>     inefficiently search the tuple for an object of appropriate type every<br>
>     time. What am I missing here?<br>
><br>
><br>
> You're not missing anything, you just have to pay for the search cost,<br>
> otherwise we're back to square one here of not worrying about the case<br>
> of multiple users. I don't see how you can have multiple users of a<br>
> single struct field and yet not have to do some search of some data<br>
> structure to find the relevant object you care about. We've tried maps<br>
> and dicts and they were too slow, and we proposed not worrying about<br>
> multiple users but people didn't like the idea of either not caring or<br>
> relying on some implicit practice that  evolved around the co_extra<br>
> field. Using a tuple seems to be the best option we can come up with<br>
> short of developing a linked list which isn't that much better than a<br>
> tuple if you're simply storing PyObjects. So either we're sticking with<br>
> the lack of coordination as outlined in the PEP because you don't<br>
> imagine people using a combination of Pyjion, vmprof, and/or some<br>
> debugger simultaneously, or you do and we have to just eat the<br>
> performance degradation.<br>
><br>
Could the users register themselves first? They could then be told what<br>
index to use.<br></blockquote><div><br></div><div>But that requires they register before any tuple is created, else they run the risk of seeing a tuple that was created before they registered. To cover that issue you then have to check the length at which point it's no more expensive than just iterating through a tuple (especially in the common case of a tuple of length 1).</div></div></div>