> That's already the case for 3.11
Ah, that's awesome news! Like with the rest, I'll wait and see what shape this
ends up taking :).
Cheers,
Gab
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to
Hi Gabriele,
>> So this makes me wonder if it would make sense for CPython to ensure
frame objects are created in a contiguous block of memory (perhaps there
could be benefits from the locality of reference, although it's not obvious
to me why this would be the case at the moment).
That's
Brandt, Guido, Pablo
Many thanks for your helpful answers. Indeed I'm asking because I just
finished working on some improvements to Austin and got back to looking
into what was coming in order to add support for 3.11 (plus make use of
some of the changes that I recently contributed, like
Hi Gabriele,
In addition to what Guido and Brandt have already said, I can help to you
adapting Austin to 3.11 as I reviewed or authored some of these changes and
I have already been helping some projects do the relevant changes as well
as in my own tools.
What you want to do si the following
Hi Gabriele,
I think the code is currently the only documentation, since this is
considered a CPython internal issue. I'm CC'ing Mark Shannon, since he
designed this for 3.11.
For a bit of background, see this issue in the Faster CPython tracker:
https://github.com/faster-cpython/ideas/issues/31
Just to clear up a quick point I made:
> - PyFrameObject.f_back just gives you a dummy wrapper around the previous
> frame object.
> - It's not really useful for unwinding anything.
That should read "previous InterpreterFrame", rather than "previous frame
object".
Also, everything I wrote
Hi Gabriele!
> I hope you would indulge me in asking for some details about the new CFrame
> structure, even in the form of existing literature (e.g. PEP) where the idea
> behind it is explained.
There isn't too much documentation on this, unfortunately (since these are all
very unstable,
