[dekhn]

IronPython, based on CLR and .NET, was faster than Python and didn't have a GIL.

[dagw]

IronPython also wasn't compatible with any python library that used the C API. Essentially we're back to the point that removing the GIL is 'easy' as long as you don't care about backwards compatibility.

[dekhn]

in many ways ironpython obviated the C API. It had a different approach to extension, based on CLR and .NET. Even the containers used .NET data types.

[dagw]

Oh absolutely, but that did make IronPython more of a separate language that shared syntax with cpython rather than a drop in replacement for cpython.

[chrisseaton]

But, again, IronPython does not have the same semantics as standard Python, so this would be a breaking change to adopt, and so would need to be Python 4.

[pansa2]

IIRC it included a JIT compiler, which was fast enough to offset the overhead of fine-granularity locking.

[zerkten]

You have to consider the use case in addition to the technology. The relatively simple implementation of CPython ensures you have fast startup, but trade-off other optimizations which affect long-running programs.

Lots of Python scripts only run for a short time. Code in the REPL needs to return results really quickly. The .NET JIT added significant startup costs to the point where the IronPython team had to add an interpreted mode for first runs before handing off the JIT. This is complex and arguably takes time away from CPython compatibility work.

It seems that the .NET team is coming around to the concerns around startup time, but I don't know if they have landed on an AOT solution. It probably will help executables running on .NET Core more than scripts running under IronPython. I've not kept up with JITs very much, but I don't think this pattern is limited to the .NET JIT, and is a general trade-off. I feel like JavaScript JITs may be closer to what IronPython would have wanted though.