On Mon, 16 May 2016 at 20:50 Nick Coghlan email@example.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 firstname.lastname@example.org 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.
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 :).
-- Nick Coghlan | email@example.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Pythonfirstname.lastname@example.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/