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

[Brett Cannon]

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


>
> > 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 :).

-Brett


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