[Python-Dev] Tweak to PEP 523 for storing a tuple in co_extra (original) (raw)

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 coextra 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.coextra += (FunctionStats(),) return func Tuple immutability impacts the initialization only. After that, you just iterate over it. I wasn't aware we wanted to expose coextra 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