Python for .Net rises from the dead

Development on IronPython, a Python implementation that runs on the .Net framework’s Common Language Runtime (CLR), is getting a shot in the arm thanks to the project recently changing hands to a new development lead.

Jeff Hardy, former lead IronPython developer, confirmed the transition on the Ironpython-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,” Hardy wrote, “so I’m handing control of the project to [fellow project contributors] Alex Earl and Benedikt Eggers.”

A Python for .Net, and vice versa

IronPython, written in C#, is not just meant to run stock Python programs. It can provide Python programmers with a bridge to existing .Net applications and objects. Best of all, those objects can be imported and handled with the same syntax and idioms as native Python objects.

Development on IronPython has unquestionably slowed over the past couple of years. The last major release was for Python 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, and Python 3 is the established successor.

In a meeting on developer chat site Gitter, Earl, Eggers, and others hashed out the most urgent issues facing the project as it moves forward: what to do about outstanding IronPython issues on CodePlex; what kind of release schedule to implement; and what sort of road map to devise for IronPython 3.

Another issue that came up in discussions was how to implement support for Python libraries that use C extensions. If IronPython is to have the broadest possible audience, this isn’t an option. Many major Python libraries, like Numpy, use C extensions for speed, and they should ideally work as-is in IronPython without needing to be recompiled.

The good 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 and will need to be heavily revised to be useful for modern Python.

Of rubies and GILs

Another issue that came up was how to deal with a similar project handled by the same team: IronRuby, which is a .Net implementation of Ruby, as the name implies. The two languages have been co-developed, since they originated from the same efforts within Microsoft around the Dynamic Language Runtime, and remained in close proximity after Microsoft spun them off into community-driven efforts in 2010.

The plan is to make IronRuby its own project to attract its own developer audience. IronPython 2 will also continue to be developed as a discrete project.

Future IronPython development may prove fruitful by providing a way to fulfill the long-standing dream of a fast, multicore-friendly Python runtime. IronPython does not have a Global Interpreter Lock (GIL), a feature of many Python implementations that’s been 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 are markedly worse. For now, simply bringing IronPython up to speed with the current branches of Python, 2 and 3 alike, ought to be mission enough.