IronPython 2.6 and the Roadmap Beyond
The IronPython team just released IronPython 2.6 Release Candidate 1.
Since the release there have been a few changes and a few bug reports so there will be another release candidate before the final release.
Harry Pierson, IronPython Program Manager, has done two blog entries discussing what is in the new release and the roadmap for IronPython beyond the 2.6 release.
If you have opinions about how IronPython should move forward then leave a comment on either of these blog posts.
Since the release there have been a few changes and a few bug reports so there will be another release candidate before the final release.
Harry Pierson, IronPython Program Manager, has done two blog entries discussing what is in the new release and the roadmap for IronPython beyond the 2.6 release.
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.
- Python 2.6 features such as with statement, class decorators and byte literals
- Adaptive Compilation
- __clrtype__ Metaclasses
- ctypes and frames support
- Lightweight Debugging
- 417 bugs fixed!
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...
It’s not quite out the door yet, but things have gotten quieter around here since we shipped the Release Candidate of 2.6. But there’s no rest for the dynamic, so we’ve already started thinking about what we do next.
Since we shipped 2.0 last December, we’ve shipped two service releases: 2.0.1 two months later in February and 2.0.2 four months after that in June. We weren’t planning on doing a 2.0.3 release, but then we discovered the CLR folks made a breaking change to partial trust in Windows 7. David recently emailed the IronPython mailing list looking for feedback on other must-fix bugs we can get to for 2.0.3. If you’ve got an opinion on 2.0.3 must-fix bugs, please respond to that thread.
...
At this point, we’ve got the next few months mapped out, but not much more beyond that. Specifically, we have two gaping holes in the roadmap:
For now, I’m going to leave these holes unfilled. Currently, the rest of my VS Languages teammates (along with the rest of DevDiv) are heads down driving towards beta 2 of Visual Studio 2010. Once they reach that milestone, planning on Visual Studio v.next will begin. Those plans have the potential for impacting how the IronPython team proceeds going forward.
- Visual Studio Integration
- IronPython 3.x
If you have opinions about how IronPython should move forward then leave a comment on either of these blog posts.
Does 2.6 include the complete standard library so that stuff like ElementTree work out-of-the-box? That would be the biggest enhancement for us and would considerably help getting Robot Framework [http://robotframework.org] fully supported on IronPython.
ReplyDeleteIronPython has, ever since 2.0, included all of the standard library that successfully imports in IronPython. (Not all of it works completely - but a lot of it is there.)
ReplyDeleteIronPython 2.6 has Python stack frames (optionally), so there are *more* standard library modules than there were in previous releases.
Off the top of my head I don't know if ElementTree is included but it would be easy to check...
For XML support with IronPython you should look at FePy. This includes a version of pyexpat in pure Python (using .NET XML libraries under the hood) and enables more of the Python standard library XML modules to work with IronPython.
Good to hear that the situation with the standard library is getting better. I also hope improvements related to that get at least some priority in the future roadmap.
ReplyDeleteGeneral incompatibilities have a high priority, particularly if the stop things from running. Where you find them report them on Codeplex and include in the report a note that the problem prevents the use of a particular library or application.
ReplyDeleteMissing modules is slightly different and often a lot more work to fix (the same is true for Jython and PyPy of course). The underlying cause is usually a Python standard library C extension that hasn't been implemented for IronPython. Make sure there is an issue on Codeplex for the specific module - vote for it if there is an issue already or create an issue if there isn't.
Issues with more votes get higher priority - so if you have issues that are important to you then you can canvas for votes on the IronPython mailing list. :-)
A *faster* way of getting things to work is to implement (and release as open source) a wrapper library yourself. :-)
Yep, we'll definitely submit issues, and patches, for the bugs we encounter when we start to look at full IronPython support for Robot Framework. We've done the same with Jython already.
ReplyDeleteRelated to implementing wrapper libraries, why isn't FePy code like pyexpat included into IronPython? Some annoying copyright or license issues?
Yeah - IronPython can't currently take submissions from anyone outside of Microsoft.
ReplyDelete