Jason Zander has announced that Microsoft will be turning over IronPython and IronRuby to Miguel de Icaza of Novell/Mono and former IronRuby lead Jimmy Schementi. Jimmy left Microsoft in July to join Lab49. IronPython will have two additional coordinators: Michael Foord, co-author of IronPython in Action and IronPython MVP Jeff Hardy. This has already led to import changes in how the projects operate.
- The community can now make source contributions to any component of IronPython and IronRuby.
- For both IronPython and IronRuby, we’ve made changes to the CodePlex projects to allow community members to make contributions without Microsoft's involvement or sponsorship by a Microsoft employee.
- We’ve already released the IronPython Tools for Visual Studio that we developed under Apache 2.0. We’ve received great early feedback on the IronPython language service for Visual Studio. Today we are releasing the prototype code for IronRuby Tools for Visual Studio, and we expect similar feedback for IronRuby tools as well. Releasing these components under the Apache 2.0 license allows for community members to use the functionality and also contribute to the IronPython and IronRuby language services.
- We have done a lot of ground work for the next version of IronPython v2.7 and IronRuby v1.9.
- We have fixed a lot of infrastructure so that the community should be able to regression test all language updates using our tests.
- We have enabled a full release work flow to produce builds and releases straight from the CodePlex projects. Previously, these could only easily be done from our own source depots.
Jeff Hardy adds,
Do note that Zander doesn't actually come out and *say* that Microsoft is no longer funding IronPython/IronRuby, but that's what has happened. Any future participation from MS employees will be on an unofficial, spare-time basis.
All that said, I hope this isn't the end of IronPython. There's a good community here, and I think we can do just as good a job as Microsoft did. You can now contribute patches to IronPython, but that means you will have to if you want the it to flourish. A good Open Source community requires a core of regular contributors, but also requires a mass of occasional ones that are just scratching their particular itches.
The Iron Languages started as prototypes to determine if the Common Language Runtime would be capable of supporting dynamic languages. The project evolved along with the CLR until it reached the point where a unified object model was created so that different dynamic languages could interoperate. The final result of this effort, known as the Dynamic Language Runtime, is now shipped as part of .NET 4.0.
According to Jeff Hardy, there are two “rings” to the Dynamic Language Runtime.
The inner ring is the expression tree extensions, call sites, and some other infrastructure stuff - this is what shipped with .NET 4 was previously in Microsoft.Scripting.Core.dll. The outer ring in the hosting APIs - ScriptEngines, Scopes, etc. It is in the hands of the community now and we can do with it as we please.
As far as I know, the inner ring/.NET 4 parts are pretty solid - there may be a few changes, but they're likely pretty minor, and hopefully MS is willing to work with us (and projects like IronJS, Coljure-CLR, & IronScheme) if changes are needed.
The outer ring is also pretty solid as well, as far as I know, but it's not a concern since it can be changed at will (except that multiple projects depend on it, so some caution would still be needed). We might have to start calling that part DLR+ or something to avoid confusion.
Jim Hugunin, creator of Jython and major contributor to IronPython, will be leaving Microsoft for a position at Google. Google is well known for its use of Python, so he will undoubtedly receive a warm reception there. Jim writes,
Microsoft's decision to abandon its investment in IronPython was a catalyst but not the cause of my leaving the company. While most of you know that I haven't been directly involved in IronPython for quite some time, the decision still provided a spur to cause me to reflect on my time at the company and realize that it was time to explore other career options. There would be something emotionally satisfying about leaving Microsoft in a fit of rage - preferably involving the illegal deployment of an emergency escape slide. However, I leave feeling respect for the many great people and products produced here. I will suffer some pain when I have to write code in Java now that I've learned to love the elegance of C#. I will suffer some frustrations when I have to use Google Docs instead of the finely polished UI in Microsoft Office. More than anything, I will always value the chance that I had to work with and learn valuable lessons from some truly great people.
In related news, IronPython 2.7 has just hit the beta stage. In the release notes Dino Viehland writes,
Python 2.7 includes a number of features backported from the Python 3.0 series. This release implements the new builtin _io module, includes dictionary and set comprehensions, set literals, supports multiple context managers in the with statement, and adds several new functions to the itertools methods, and auto indexing for the new string formatting. There are also numerous updates to the standard library such as ordered dictionaries and the new argparse module.
This release also includes a "IronPython Tools for Visual Studio" option within the IronPython installer. This enables one install to get both IronPython and IronPython Visual Studio support assuming you have an existing installation of Visual Studio 2010. This version of IronPython Tools includes a number of bug fixes as improved WPF designer support. The designer fully supports XAML and WPF including data binding to Python classes dynamically.
We've also updated the IronPython installer to include documentation based upon the CPython documentation. This new .chm file includes documentation on the Python language and standard library. It's been extended from the normal Python documentation to include IronPython specific topics such as the DLR hosting APIs and extending IronPython from statically typed .NET languages.
We flushed out more support for missing built-in modules which CPython includes. This release includes the mmap and signal modules bringing better support for interoperating with unmanaged code.
As usual there are a number of bug fixes and performance improvements. This release includes major performance improvements in cPickle, the sum built-in function, and includes support for fast exceptions which do not use the .NET exception mechanism. There have also been improvements to significantly reduce memory usage of the IronPython ASTs. One of the end results of these numerous improvements is that IronPython's startup time has decreased by 10% when compared to IronPython 2.6.1.
