I wouldn't expect *exactly* the same outcome, but I would expect an outcome compatible with the language's semantics (and I believe PyPy delivers on this). Where life gets harder are things like C extensions, which are often (not intentionally) intertwined with CPython's implementation.

doc.pypy.org/en/latest/cpython_differences.html

My impression was that PyPy was nearly 100% compatible with "normal" Python programs, but you could get off in the weeds with certain techniques like stack frame introspection, C extension modules, etc.

I believe the biggest incompatibility is that if you rely on when objects are collected it will be different. For C extensions it's mostly if they tried to use internals of the implementation (which happens of course).

I wouldn't call the GC aspect an incompatibility per se; rather it is programs and programmers assuming that a particular implementation is coterminous with the specification. This can feel like a pedantic distinction to many folk, I admit.

I agree with that, I mostly mean that if code runs in CPython and then breaks in PyPy in 2025, that's the most likely reason.

CPython on Windows and CPython on Linux or Mac aren’t going to have the same behavior for all programs either. I don’t think it’s pedantic.

Aside from code relying on private implementation details, most of the other incompatibility is like GC -- code that's non-deterministic on both systems but PyPy is mostly or all one way while CPython is mostly the other way.

The language is actually RPython is what I thought - rpython.readthedocs.io/en/latest/rp... . I suppose such a speed up effort is made somewhat redundant by Mojo. The lang must change tho. Python's __fn__ dynamics is its strength for flexibility and its Achilles heel for performance.

RPython is really only meant for writing interpreters in ("RPython" is best thought of as both a restricted subset of Python / a language, and a meta-tracing system).