[Python-ideas] Adding a frame evaluation API to CPython

Brett Cannon brett at python.org
Tue May 17 11:10:47 EDT 2016

On Mon, 16 May 2016 at 20:50 Nick Coghlan <ncoghlan at gmail.com> wrote:

> This idea generally sounds reasonable to me, I just have some
> suggestions for other folks to approach specifically for feedback.
> On 17 May 2016 at 06:19, Dino Viehland <dinov at microsoft.com> wrote:
> > Other JITs
> > It should be mentioned that the Pyston team was consulted on an earlier
> version of this PEP that was more JIT-specific and they were not interested
> in utilizing the changes proposed because they want control over memory
> layout they had no interest in directly supporting CPython itself. An
> informal discusion with a developer on the PyPy team led to a similar
> comment.
> > Numba https://github.com/Microsoft/Pyjion/blob/master/pep.rst#numba, on
> the other hand, suggested that they would be interested in the proposed
> change in a post-1.0 future for themselves
> https://github.com/Microsoft/Pyjion/blob/master/pep.rst#numba-interest.
> Hopefully Victor will chime in anyway, but if he doesn't, I'd suggest
> asking him directly what impact this proposal might have on the
> bytecode transformation aspects of PEP 511.

There won't be any direct impact and would actually benefit from it as any
improved bytecode emission would mean better JIT output. But that's getting
rather JIT-specific and this PEP tries to only use JITs as a motivation,
not the exact/only reason to add this API.

> There also seems to be a potential overlap with the function
> specialisation proposal in PEP 510, so it would be good to see this
> PEP discussing its relationship with that one (the explanation may be
> "they're orthogonal proposals addressing different concerns", but it
> isn't immediately obvious to me that that's actually the case)

"They're orthogonal proposals addressing different concerns". :) While a
JIT may be able to benefit from it, the JIT aspect is simply a use of the
proposed API (we have purposefully tried not to pain ourselves into a
corner of being a JIT-only thing). IOW I purposefully didn't draw in other
perf PEPs relating to bytecode as it isn't directly related to the overall

> > Debugging
> > In conversations with the Python Tools for Visual Studio team (PTVS)
> https://github.com/Microsoft/Pyjion/blob/master/pep.rst#ptvs, they
> thought they would find these API changes useful for implementing more
> performant debugging. As mentioned in the
> https://github.com/Microsoft/Pyjion/blob/master/pep.rst#rationale
> section, this API would allow for switching on debugging functionality only
> in frames where it is needed. This could allow for either skipping
> information that sys.settrace() normally provides and even go as far as to
> dynamically rewrite bytecode prior to execution to inject e.g. breakpoints
> in the bytecode.
> I'd suggest reaching out directly to Dave Malcolm on the GNU tools
> team in relation to this aspect, as I believe he did a lot of the work
> for the improved CPython runtime support in gdb 7+:
> https://docs.python.org/devguide/gdb.html
> That support currently mostly works at the frame level, so it would be
> interesting to know what additional capabilities might be enabled by
> being able to selectively intercept code execution at the bytecode
> level.

I'll shoot him an email (and based on how you phrased that I'm going to
assume you said it with your work hat on and he's still at RH :).


> Cheers,
> Nick.
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160517/898ac8bd/attachment.html>

More information about the Python-ideas mailing list