On 5 March 2016 at 19:49, Paul Moore <p.f.moore@gmail.com> wrote:
On 5 March 2016 at 04:25, Larry Hastings <larry@hastings.org> wrote:
- The only exception I know of is Lua--are there more?
TCL and Racket (was mzscheme). I think the key thing is that languages designed for embedding provide a C API. Python supports embedding, so if we did move away from the C API, we'd need to be very careful not to make it harder to embed Python (or deprecate embedding altogether, but I don't think that's realistic - quite a few projects embed Python).
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.
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)
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.
Regards, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia