IronPython 2.6 and the Roadmap Beyond

By Michael Foord -
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.
As I’ve written before on this blog, this is a HUGE release for us:
  • 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!
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...
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:
  • Visual Studio Integration
  • IronPython 3.x
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.

If you have opinions about how IronPython should move forward then leave a comment on either of these blog posts.

Comments

  1. Pekka Klärck10/05/2009 4:38 pm

    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.

    ReplyDelete
  2. Michael Foord10/05/2009 4:44 pm

    IronPython 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.)

    IronPython 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.

    ReplyDelete
  3. Pekka Klärck10/05/2009 5:07 pm

    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.

    ReplyDelete
  4. Michael Foord10/05/2009 5:12 pm

    General 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.

    Missing 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. :-)

    ReplyDelete
  5. Pekka Klärck10/05/2009 5:39 pm

    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.

    Related to implementing wrapper libraries, why isn't FePy code like pyexpat included into IronPython? Some annoying copyright or license issues?

    ReplyDelete
  6. Michael Foord10/05/2009 5:50 pm

    Yeah - IronPython can't currently take submissions from anyone outside of Microsoft.

    ReplyDelete

Post a Comment

Popular posts from this blog

Extending Abobe Flash Player and AIR with Python and Ruby

By Michael Foord -
An intriguing blog entry about an Adobe experimental project. It is a C/C++ cross- compiler for the flash player and AIR. This means that you can (will be able to?) cross-compile the Python / Ruby/ lots of other language runtimes and then run them in Flash. The blog entry contrasts this approach to the DLR which requires the re-implementation of dynamic languages - hence IronPython and IronRuby. The project is already beyond proof-of concept, they even have Quake III cross-compiled and running in Flash. Extending Adobe Flash Player and AIR with C/C++ Cross-Compiler Quake 3 has already been ported to managed code , but this is even more impressive. Whether the Python interpreter can be cross-compiled to run on top of another runtime (with completely different basic types), without changing the language semantics at all, has yet to be proved - but it is a very interesting project. (It also means that Python/Ruby will possibly be enabled only by additional optional downloads - but don'
Read more

Should Python Projects Support IronPython and Jython?

By Michael Foord -
The maintainers of the Spring Framework for Python ( Spring Python ) wonder how much of a priority it is to have compatibility with platforms other than CPython. In other words, should they support IronPython and Jython - and if so what should they do about their C extension dependencies? This question sparks a good discussion and is relevant to many other Python projects and applications: Need for supporting IronPython, Jython? " One of the topics on my mind recently, as we consider refactoring the core container, is how we ensure that when we introduce internal dependencies, such as possibly the Amara libraries for XML processing, what secondary constraints we might be introducing. " " For example, Amara represents a very pythonic and therefore simple to read and use approach to developing XML processing, such as our very own XML application configuration parsers. So from that perspective, things are very attractive. But then you ask the question, "can I run this
Read more

Further Adventures of the Debugger

By Michael Foord -
Harry Pierson (Microsoft IronPython PM) has been experimenting with writing an IronPython debugger ( ipydbg ) on top of the .NET MDbg APIs. When we last left him , he had implemented Just My Code (JMC) support allowing you to step into IronPython code. Since then he has made a lot of progress including a colourful REPL (interactive console) and solving some difficult problems around getting to real values behind boxed IronPython variables (needed for showing local variables). He has blogged extensively on what he has been up to (more recent posts last): Showing Source Code Colorful Console IronPython ConsoleColorMgr (the colorful console code pulled out into a separate IronPython module) A Little Hack...err...Cleanup Getting Local Variables Displaying Values Command Routing Getting Arguments REPL Console A lot of functionality is now present. In the command routing entry Harry outlines the seven commands supported by the debugger so far: Continue, Quit, Show Stack Trace, Show Locals,
Read more