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.

> It can use all the C libraries natively

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.

This is wonderful news to me. So broadly speaking I should be able to drop in replace cpython with pypy for my fairly not so special projects?

I have a Django app that does some heavy data serialization and I'm not yet ready to optimize those serializers in another language.

I can't wait to try this out.

Crumb. I didn't realise pypy is on 3.5.3. Loves me my f strings.

We backported fstrings to 3.5. We also have an alpha quality linux 3.6 available on nightly builds

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.

f-strings were "backported" to pypy and work fine.

No, numpy and pandas break with every new release, support for them is constantly lagging behind. Other C libraries too...

PyPy should be releasing soon, if you use cutting edge then you have to use cutting edge PyPy as well

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.

> CPython is really quite slow by design.

The data structures are slow by design.

The way we use these data structures is quite inefficient.

Having a fast interpreter only about doubles the execution speed in most programs leaving another factor of 50 open for future generations.

Really ? I though Python dicts and lists were actually quite fast for a dynamic language.

Ints and classes can be slow though.

Anything I don't know ?

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.

I though you were stating that Pythn were slow compared to what it could be, being a dynamic language.

Of course if you compare to static languages it's slow. Of course you can write low level specialized DS. Duh.

Awesome!

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.