<br><br><div class="gmail_quote"><div dir="ltr">On Sat, Sep 3, 2016, 17:45 Yury Selivanov <<a href="mailto:yselivanov.ml@gmail.com">yselivanov.ml@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
><br>
>  Â  Â But without that new API (basically what Christian proposed) you'd<br>
>  Â  Â need<br>
>  Â  Â to iterate over the list in order to find the object that belongs to<br>
>  Â  Â Pyjion.<br>
><br>
><br>
> Yes.<br>
<br>
Yeah, which means the same for my opcode patch... Which unfortunately<br>
will make things slower :(<br>
<br>
>  Â  Â  Â If we manage to implement my opcode caching idea, we'll have at<br>
>  Â  Â least two known users of co_extra.  Without a way to claim a<br>
>  Â  Â particular<br>
>  Â  Â index in co_extra you will have some overhead to locate your objects.<br>
><br>
><br>
> Two things. One, I would want any new API to start with an underscore<br>
> so people know we can and will change its semantics as necessary. Two,<br>
> Guido would have to re-accept the PEP as this is a shift in the use of<br>
> the field if this is how people want to go.<br>
<br>
<br>
Since this isn't a user-facing/public API feature, are we *really*<br>
forced to accept/implement the PEP before the beta?<br></blockquote></div><div><br></div><div>I say yes since people could want to use it during the beta for testing (it's Ned's call in the end, though).</div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I'd be happy to spend some time tomorrow/Monday to hammer out an<br>
alternative approach to co_extra. Let's see if we can find a slightly<br>
better approach.<br></blockquote></div><div><br></div><div>OK!</div><div><br></div><div>-brett</div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Yury<br>
</blockquote></div>