Home Original page

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

Chris Angelico rosuav at gmail.com
Sat Sep 3 20:15:27 EDT 2016 
On Sun, Sep 4, 2016 at 9:49 AM, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
>
>
> On 2016-09-03 4:13 PM, Chris Angelico wrote:
>> 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.

If everyone behaves properly, it should be safe.

tuple_pointer = co_extra
max_index = len(tuple_pointer)
is tuple_pointer[0] mine? No
-- someone appends to the tuple --
is tuple_pointer[1] mine? No

The only effect of caching is that, in effect, mutations aren't seen
till the end of the iteration - a short time anyway.

>> 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.

This is what I get for overly embracing the notion that Python is
executable pseudo-code :) Yes, this would normally be happening in C,
but notionally, it'll be like that.

ChrisA
More information about the Python-Dev mailing list