I have ported code from Cinder to CPython . The fork has some optimizations that can be easily put in CPython and Facebook is open to port features. I’m not sure if Facebook wants to continually have a fork but CPython is open to have those features merged in if they make sense.

The Cinder team's longterm goal is to upstream as much as we can, and make the rest available as pip-installable extensions that anyone could theoretically install and use on CPython. The fewer internal changes and patches we need to maintain, the faster we can adopt upstream Python releases and all of the associated performance and tooling wins.

Okay cool thanks for the clarification

I've been following it with updates from Talk Python To Me and Python Bytes.

Great work, much appreciated.

That seems like pretty much the perfect way to go about things. Kudos on that work!

Mind that Python 3.10 is nine major versions ahead of 3.1

*minor

:s/major/minor

No, I meant major. Each of the 3.x releases brings in new features, deprecations, and even sometimes removed features. They are all major releases.

Python doesn't go by semver rules. Semver isn't a definition for all software project versioning systems everywhere.

You are factually wrong.

"To clarify terminology, Python uses a major.minor.micro nomenclature for production-ready releases. So for Python 3.1.2 final, that is a major version of 3, a minor version of 1, and a micro version of 2.

* new major versions are exceptional; they only come when strongly incompatible changes are deemed necessary, and are planned very long in advance;

* new minor versions are feature releases; they get released annually, from the current in-development branch;" — https://devguide.python.org/developer-workflow/development-c...

Good point 3.10 != 3.1

Python is a spec not an implementation, for what it is worth.