<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 5 March 2016 at 19:49, Paul Moore <span dir="ltr"><<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 5 March 2016 at 04:25, Larry Hastings <<a href="mailto:larry@hastings.org">larry@hastings.org</a>> wrote:<br>
> * The only exception I know of is Lua--are there more?<br>
<br>
</span>TCL and Racket (was mzscheme). I think the key thing is that languages<br>
designed for embedding provide a C API. Python supports embedding, so<br>
if we did move away from the C API, we'd need to be very careful not<br>
to make it harder to embed Python (or deprecate embedding altogether,<br>
but I don't think that's realistic - quite a few projects embed<br>
Python).<br></blockquote><div><br></div></div>I actually want to make embedding CPython even easier (ideally ending up in a situation where we can offer a shared embedding API with MicroPython), but that's a time consuming task that requires a pretty deep knowledge of CPython's startup and shutdown sequences.<br><br></div><div class="gmail_extra">I'm pretty happy with the general design and proposed implementation strategy in PEP 432 now, but it's sufficiently far removed from anything I'm doing for work that it isn't a project I can pick and work on for a few hours here and there. (Which also creates problems for coaching anyone else in tackling it - this project touches parts of the interpreter that *I* have to relearn in order to work on it effectively, and it's mainly the relearning that's the time consuming part rather than the actual work)<br><br></div><div class="gmail_extra">That said, there's already some pretty interesting work in embedding based cross-runtime bridges (metabiosis for CPython-in-PyPy, jitpy for PyPy-in-CPython, Lunatic Python for both Lua-in-CPython and CPython-in-Lua, Julia's native bidirectional Python bridge), so I suspect development energy around "Python without the CPython C API" could be directed towards some of those combinations, rather than trying to significantly refactor CPython itself.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Regards,<br></div><div class="gmail_extra">Nick.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia</div>
</div></div>