IronPython 2.6 Release Candidate

We released the IronPython 2.6 release candidate on CodePlex yesterday. If all goes well, this will be the ONLY RC and we’ll republish it as the RTW build in about a month. So if you’ve been holding off on experimenting with the 2.6 release, now’s the time to jump in with both feet.

As I’ve written before on this blog, this is a HUGE release for us:

Anyway, with 2.6 winding down, the IronPython team finds ourselves in a unique position that we’ve never been in before: caught up. As far as I can tell, most of the Python community hasn’t made the move to Python 3.1 and Python 2.7 is looking like it will be released next summer. So IronPython is caught up with the latest version of Python most of the Python community appears to be using.

So that begs the question: what do we do now?

Of course, we want to hear from you regarding our next steps, but some things we are looking at include:

  • .NET Framework 4.0
    We’ve shipped CTP releases of IronPython for each public beta of Visual Studio 2010 and  .NET Framework 4.0. You can expect that to continue as Visual Studio 2010 winds down and ships.
  • Fixing Bugs
    417 bugs fixed is good, but there are still 839 active work items in our issue tracker. In previous releases, we’ve done minor bug fix releases every few months so we’ll probably keep up that cadence. Make sure you go vote for bugs you think are important.
  • App Compatibility
    One thing we can do is take some of the more popular Python apps such as Django and Mercurial and make sure they run well on IronPython. In some cases, there may need to be changes to the Python apps to get them to run on IronPython (for example, see Jeff Hardy’s patch for running Django on IronPython) which assuredly means more time with lawyers for me.
  • Missing Modules
    While IronPython 2.6 is our implementation of Python 2.6, there are binary modules we haven’t implemented yet like _csv, _ast and pyexpat. You could consider this App Compatibility work, but we have a different internal process for bug fixing and implementing new features so I broke this out separately.
  • Documentation
    Invariably an area for improvement in all software, our doc story today is pretty much “go look at”. Of course, that doesn’t cover any IronPython specific functionality. Of course, what would be great would be to combine existing Python docs with IronPython specific docs in a single reference, which also assuredly means more time with lawyers for me.
  • Tutorials
    If you haven’t seen Michael Foord’s Try Python, it’s awesome. However, it was recently pointed out to me that it doesn’t include any IronPython specific behavior (importing and interoperating with .NET types for example). The IronRuby Tutorial has specific IronRuby features and it would be awesome to do the same for IronPython. Of course, if we wrote new tutorials in reStructured Text, then I’m guessing it would be easy for Michael to include it in Try Python via his rst2xaml tool.
  • “Just Text” in Silverlight
    If you haven’t seen MIX Online Labs Gestalt project, browse to one of the samples and View Source. Python as “just text” in the browser. Cool, eh? Jimmy is working on implementing the “just text” model for the Silverlight version of IronPython (and IronRuby).
  • Visual Studio
    There’s no work item for VS Integration in our issue tracker, but there have been 112 votes for IronPython integration (as well as 79 votes for IronRuby integration) in the VS 2010 connect bug database. No promises here, but we are acutely aware of how popular this suggestion is.
  • CodePlex Foundation
    The CodePlex Foundation is a new non-profit foundation sponsored by Microsoft with the explicit mission “to enable the exchange of code and understanding among software companies and open source communities.” As one of the oldest open source projects at Microsoft, we are very interested in the CodePlex Foundation as you might imagine. However, CodePlex Foundation is VERY new – everything is tagged “interim” for the first 100 days. Once the Foundation elects non-interim board members and establishes things like a charter and by-laws, you can be sure we’ll be investigating it more thoroughly. In other words, definitely more time with lawyers for me.

In case I haven’t said it lately, it’s great working on the IronPython team with Dino Viehland, Dave Fugate and David DiCato (The IronRuby guys aren’t bad either!). Also, I may whine about the amount of time I spend with lawyers, but honestly Yong, Kathryn and Kevin – our main LCA contacts – do a great job helping us figure out how and where to push the envelope so thanks to them as well.


Adding an IronPython tutorial to Try Python is on my todo list. :-) If you guys can contribute something first then that would be awesome of course... :-)
Visual Studio integration, without a doubt. This would be huge for a variety of reasons; I want to use a familiar editor, I want to build mixed-language projects without managing multiple toolsets, makes it easier for my team to take it seriously, etc., etc.
App compatibility would be on top of my list especially since on the web space, there is no major python framework is currently working out of the box on IronPython and that's a pretty major gap.
I haven't been able to find any statements about 3.x: Is there a plan for 3.x support or is it a question of critical mass?
Until you have a form designer and intellisense IronPython is just a toy compared to C#, only good for embedding scenarios. And with C# 5 I can just use C# as an embedding language instead.
I would be most happy with import time improvement, specifically importing from dll (python compiled into dlls).
Harry, Is there a better place for people to suggest / vote for features than in these comments? Maybe on the IP mailing list? Or is here fine? Personally, start up time is the only thing that bugs me on a daily basis, and makes me think twice when I'm choosing between IronPython or CPython for new personal projects. Bengt: There's nothing to stop you using the Visual Studio form designer and then just inheriting from those generated forms in IronPython. We do that with new GUI components all the time where I work.
I'd love to see you guys work on performance as benchmarked in some realistic scenarios (e.g. Unladen Swallow are using the Django templating engine for benchmarking). I don't think microbenchmarks at all show the performance issues for large Python apps. In general running IronPython with larger Python codebases (Django, Trac, Mercurial) would shake out both comaptibility *and* performance issues which I think are the most important. :-) Oh - getting pdb working *fully* with IronPython 2.6 would be awesome by the way.
@Bengt I don't see how generating forms in IronPython is particularly interesting. Visual Studio integration *is* interesting but the form designer should be at the bottom of the priority list for integration. You can already use the forms designer to generate C# and use that from IronPython very easily.
@Bob, We're big fans of Python 3k (though we'll skip 3.0 and go directly to 3.1) as ascii stings is a big source of incompatibility for IronPython. Now that we're (almost) past 2.6, we're trying to figure out our post 2.6 roadmap including when we ship IronPython 3.1. @Jonathan, I think the best way for people to vote is to create work items on the IronPython CodePlex site since it's got a built in voting system. Also, have you looked tried the new 2.6 - I'd love to hear your thoughts on our improved startup time. @Eric, Agreed on VS integration @Dody, Agreed on app compat. Any suggestions beyond Michael's (Django, Trac, Mercurial)? and