ironclad

Right, the lack of support for C extensions in IronPython was a problem; we kicked off the IronClad project [1] to fix that -- looks like someone else picked it up later and updated it for Python 2.7 [2]. Not sure where it went after that, or whether MS fixed the underlying issue later on. [1] https://code.google.com/archive/p/ironclad/ [2] https://github.com/IronLanguages/ironclad

I should have been clearer that the other Pythons don't use reference counting. Preserving the C API can be done, see Ironclad[1] which allows using C extensions in IronPython. But assuming threadsafe collections is still a problem - that will never match single-threaded GIL Python running in multiple processes unless some efficient way can be found to optimistically make the collections not threadsafe and only pay the synchronization costs when they're really shared between threads. I think that's a solvable problem, but not with the STM approach PyPy took. Still performance will likely lag the mutli-process solution which doesn't have that cost. I would rather see a Python that introduces a way to allocate PyObjects in shared memory and with no thread safety. Since it's a new system, that can be done without breaking compatibility. Then