I've got more than a decade and a half of experience with both C++ (dating back to the relatively low quality VC6 C++ runtime) and CPython (getting on towards 20 years now), and the value of adding a C++ runtime to the CPython runtime would be vastly smaller than the value of adding it to an arbitrary C project.

If folks want rich data structures in the CPython implementation, we want them using the Python builtin types, not the C++ STL containers. If they want a type hierarchy, we want them using Python types, not C++ types. If they want automatic resource management, then we want them working out how to lift the affected code out of C and into Python (for example, the import system rewrite).

In a lot of ways, CPython's C API can be viewed as one of the many competing approaches to enabling "C-with-objects" programming, just like C++.

There are certainly nice features in modern C++ that make it easier to scale to large projects than vanilla C code, but the bulk of the CPython code base has never really been vanilla C code - it has always been able to rely on the builtin Python containers and type hierarchy for a lot of the heavy lifting.

And it is already a bigger barrier to entry than we would like to ask potential contributors to the lower level code to learn two object models (the Python one and the much simpler C one), let alone if we were to start asking them to learn a 3rd one (C++) that has a deserved reputation as one of the most complex and error prone object models in widespread use.

Cheers,

Nick.