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@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@gmail.com | Brisbane, Australia
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/