IronPython is a implementation that runs on
.NET Framework’s Common Language Runtime (CLR) is coming back thanks to the change of hands.
Jeff Hardy, former lead IronPython developer, confirmed the transition on the Ironpyton-users mailing list earlier this month.
For many reasons I just don’t have the time right now to give IronPython the attention it deserves. I’m handing control of the project to [fellow project contributors] Alex Earl and Benedict Eggers.
IronPython is written in C#, and not just meant to run stock Python programs. It can provide Python programmers with a bridge to
.NET applications and objects. The best part of it is the objects can be imported and handled with the same syntax as native objects in Python.
The development of IronPython has slowed dramatically over the past couple of years. The last major release was version 2.7.5, at the end of 2014. Python 3 wasn’t supported by IronPython — a major drawback since Python 2 will no longer be supported as of 2020.
After a meeting on the developer chat site Gitter, Earl, Eggers, and others tried to hash out the most urgent issues facing the project as it moves forward. What should be done about outstanding IronPython issues on CodePlex; what kind of release cycle to implement; and what sort of road map to devise for IronPython 3.
Another important issue that came up in discussions was how to implement support for Python libraries that require use of the C Extensions. If IronPython wants the broadest possible audience, this isn’t just an option. Many major Python libraries, like Numpy, use the C extensions for speed. They should ideally work without needing to be recompiled.
The amazing news is that some work has already been done in this area, namely Ironclad, a project devised to allow compiled CPython extensions to work as-is in IronPython. The bad news is the project hasn’t seen much work in a long time. It’s going need to be heavily revised to be useful for modern Python.
Future IronPython development may provide a way to fulfill the long-standing dream of a fast, multicore-friendly Python runtime. IronPython doesn’t have a Global Interpreter Lock (GIL), a feature of many Python implementations that’s being blamed for being a barrier to high performance.
That said, the fact that IronPython has no GIL doesn’t automatically make it faster; some IronPython benchmarks are better than CPython, but others worse off. For now, simply bringing IronPython up to speed with the current branches of Python, 2 and 3 alike, ought to be good enough for now.