CPython is really quite slow by design. The reference implementation is meant to be obvious and pretty easy to interoperate with C.
I think a RustPython implementation would be pretty cool. You could definitely take that opportunity to worry about performance more than CPython does while also worrying about interoperability more than PyPy does.
Or I'm missing your point and you're suggesting a drop-in replacement for CPython that supports all the same C-based libraries as CPython does.
PyPy is doing really well on compatibility these days. It can use all the C libraries natively, and a lot of the speed issues there have been resolved.
Literally all of them, without any issues? I'm working on implementing support for Ruby's C extensions in an alternative implementation and it's a right slog.
PyPy dev here. Yes to both - all of them and it was a right slog. If it doesn’t work report an issue. We have a proposal looking for funding to make it fast.
Great! I appreciate you sharing this. I checked the PyPy main page, Downloads page, and Compatibility page and while I didn't look exhaustively, nothing mentioned 3.6 or 3.6 features.
From my limited experience with Rust, having support for C-based libraries shouldn't be too hard to do- as Rust (like Go) has support for embedding C. I'm not sure how portable the solution would be- I would guess you would need to compile the VM with the modules you want baked in.
I think not having support for C modules would hamper long term adoption. I would absolutely love to adopt this for my stuff, but off the top of my head- I use uvloop and confluent-Kafka, both of which are largely written in in C. Moving away from those would be hard-ish.
Calling into and out of C (whether dynamically or statically linked) isn't the hard part; the hard part is implementing the somewhat arbitrary interface against which C extensions are written in a way that is functionally compatible with CPython without losing the advantages of not being CPython.
They are probably the fastest dicts and lists we can imagine today. If you really need lists and dicts for your data, you need them and won't gain much. But if you don't need them and instead could use something simpler, an array of C structs would be much faster than a list of dicts.
No, that was my point basically, although I could imagine something like this shipping with some basic libraries and package support, and then having a similar ecosystem to the current python ecosystem.
I think a RustPython implementation would be pretty cool. You could definitely take that opportunity to worry about performance more than CPython does while also worrying about interoperability more than PyPy does.
Or I'm missing your point and you're suggesting a drop-in replacement for CPython that supports all the same C-based libraries as CPython does.