On Sat, 3 Sep 2016 at 16:55 Yury Selivanov <yselivanov...@gmail.com> wrote:
> > > On 2016-09-03 4:13 PM, Chris Angelico wrote: > > On Sun, Sep 4, 2016 at 8:03 AM, Yury Selivanov <yselivanov...@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. > We are most definitely not exposing the field to Python code.
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
