<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sat, 3 Sep 2016 at 16:55 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>
On 2016-09-03 4:13 PM, Chris Angelico wrote:<br>
> On Sun, Sep 4, 2016 at 8:03 AM, Yury Selivanov <<a href="mailto:yselivanov.ml@gmail.com" target="_blank">yselivanov.ml@gmail.com</a>> wrote:<br>
>> On 2016-09-03 12:27 PM, Brett Cannon wrote:<br>
>>> Below is the `co_extra` section of PEP 523 with the update saying that<br>
>>> users are expected to put a tuple in the field for easier simultaneous use<br>
>>> of the field.<br>
>>><br>
>>> Since the `co_extra` discussions do not affect CPython itself I'm planning<br>
>>> on landing the changes stemming from the PEP probably on Monday.<br>
>><br>
>> Tuples are immutable. If you have multiple co_extra users then they will<br>
>> have to either mutate tuple (which isn't always possible, for instance, you<br>
>> can't increase size), or to replace it with another tuple.<br>
> Replace it, but only as they register themselves with a particular<br>
> function. Imagine a profiler doing something vaguely like this:<br>
<br>
"Replacing" makes it error prone to cache the pointer even for small<br>
periods of time. Defining co_extra using Python C API forces us to<br>
acquire the GIL etc (aside from other performance penalties). Although<br>
we probably would recommend to use the GIL anyways, I'm not sure tuple<br>
really simplifies anything here.<br>
<br>
><br>
> class FunctionStats:<br>
> def __init__(self):<br>
> <a href="http://self.info" rel="noreferrer" target="_blank">self.info</a> = [whatever, whatever, blah blah]<br>
><br>
> def profile(func):<br>
> """Decorator to mark a function for profiling"""<br>
> func.__code__.co_extra += (FunctionStats(),)<br>
> return func<br>
><br>
> Tuple immutability impacts the initialization only. After that, you<br>
> just iterate over it.<br>
<br>
I wasn't aware we wanted to expose co_extra to Python land.<br></blockquote><div><br></div><div>We are most definitely not exposing the field to Python code. </div></div></div>