<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Mon, 16 May 2016 at 20:50 Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This idea generally sounds reasonable to me, I just have some<br>
suggestions for other folks to approach specifically for feedback.<br>
<br>
On 17 May 2016 at 06:19, Dino Viehland <<a href="mailto:dinov@microsoft.com" target="_blank">dinov@microsoft.com</a>> wrote:<br>
> Other JITs<br>
> 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.<br>
> Numba <a href="https://github.com/Microsoft/Pyjion/blob/master/pep.rst#numba" rel="noreferrer" target="_blank">https://github.com/Microsoft/Pyjion/blob/master/pep.rst#numba</a>, on the other hand, suggested that they would be interested in the proposed change in a post-1.0 future for themselves <a href="https://github.com/Microsoft/Pyjion/blob/master/pep.rst#numba-interest" rel="noreferrer" target="_blank">https://github.com/Microsoft/Pyjion/blob/master/pep.rst#numba-interest</a>.<br>
<br>
Hopefully Victor will chime in anyway, but if he doesn't, I'd suggest<br>
asking him directly what impact this proposal might have on the<br>
bytecode transformation aspects of PEP 511.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
There also seems to be a potential overlap with the function<br>
specialisation proposal in PEP 510, so it would be good to see this<br>
PEP discussing its relationship with that one (the explanation may be<br>
"they're orthogonal proposals addressing different concerns", but it<br>
isn't immediately obvious to me that that's actually the case)<br></blockquote><div><br></div><div>"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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> Debugging<br>
> In conversations with the Python Tools for Visual Studio team (PTVS) <a href="https://github.com/Microsoft/Pyjion/blob/master/pep.rst#ptvs" rel="noreferrer" target="_blank">https://github.com/Microsoft/Pyjion/blob/master/pep.rst#ptvs</a>, they thought they would find these API changes useful for implementing more performant debugging. As mentioned in the <a href="https://github.com/Microsoft/Pyjion/blob/master/pep.rst#rationale" rel="noreferrer" target="_blank">https://github.com/Microsoft/Pyjion/blob/master/pep.rst#rationale</a> 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.<br>
<br>
I'd suggest reaching out directly to Dave Malcolm on the GNU tools<br>
team in relation to this aspect, as I believe he did a lot of the work<br>
for the improved CPython runtime support in gdb 7+:<br>
<a href="https://docs.python.org/devguide/gdb.html" rel="noreferrer" target="_blank">https://docs.python.org/devguide/gdb.html</a><br>
<br>
That support currently mostly works at the frame level, so it would be<br>
interesting to know what additional capabilities might be enabled by<br>
being able to selectively intercept code execution at the bytecode<br>
level.<br></blockquote><div><br></div><div>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 :).</div><div><br></div><div>-Brett</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
Nick.<br>
<br>
--<br>
Nick Coghlan | <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a> | Brisbane, Australia<br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org" target="_blank">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br>
</blockquote></div></div>