[Python-Dev] Tweak to PEP 523 for storing a tuple in co_extra

[Yury Selivanov]

On 2016-09-03 4:13 PM, Chris Angelico wrote:
> On Sun, Sep 4, 2016 at 8:03 AM, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
>> On 2016-09-03 12:27 PM, Brett Cannon wrote:
>>> Below is the `co_extra` section of PEP 523 with the update saying that
>>> users are expected to put a tuple in the field for easier simultaneous use
>>> of the field.
>>>
>>> Since the `co_extra` discussions do not affect CPython itself I'm planning
>>> on landing the changes stemming from the PEP probably on Monday.
>>
>> Tuples are immutable.  If you have multiple co_extra users then they will
>> have to either mutate tuple (which isn't always possible, for instance, you
>> can't increase size), or to replace it with another tuple.
> Replace it, but only as they register themselves with a particular
> function. Imagine a profiler doing something vaguely like this:

"Replacing" makes it error prone to cache the pointer even for small 
periods of time. Defining co_extra using Python C API forces us to 
acquire the GIL etc (aside from other performance penalties). Although 
we probably would recommend to use the GIL anyways, I'm not sure tuple 
really simplifies anything here.

>
> class FunctionStats:
>      def __init__(self):
>          self.info = [whatever, whatever, blah blah]
>
> def profile(func):
>      """Decorator to mark a function for profiling"""
>      func.__code__.co_extra += (FunctionStats(),)
>      return func
>
> Tuple immutability impacts the initialization only. After that, you
> just iterate over it.

I wasn't aware we wanted to expose co_extra to Python land.  I'm not 
convinced it's a good idea, because exposing, say, Pyjion JIT state to 
Python doesn't make any sense.  At least for Python 3.6 I don't think we 
would want to expose this field.

Moreover, profiling Python with a pure Python profiler is kind of 
slow...  I'm sure people use C for that anyways.

Yury