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

Yury Selivanov yselivanov.ml at gmail.com
Sat Sep 3 19:49:53 EDT 2016

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

More information about the Python-Dev mailing list