Introduction to IronPython
IronPython & Windows Forms, Part I
This is part of a series of tutorials on using IronPython with Windows Forms.
Follow my exploration of living a spiritual life and finding the kingdom at Unpolished Musings.
IronPython implements Python 2.4 and supports some Python 2.5 features.
IronPython was created by Jim Hugunin, who also created Jython, the Java implementation of Python. He started it to write an article about why the .NET framework is a terrible platform for dynamic languages. Unfortunately for Jim, it isn't.
There is already a strong community around IronPython. This has resulted in Fepy, the community edition of IronPython. It has compiled binaries for Mono, extra standard library modules and patches that haven't yet been integrated into the official Microsoft release.
So why would you want to use IronPython ? Well, apart from providing easy access to .NET assemblies, one good answer to that question is the Windows Forms API.
Windows Forms is a way to create native, rich client GUI applications with .NET. Programs created with Windows Forms can be extremely good looking, and fully programmable IronPython. At ResolverSystems we are coding a desktop application in IronPython. It is already very good. I wish I could show you some screenshots, but you'll probably have to wait until early 2007.
Despite being created by Micro$oft, the Windows Forms API is surprisingly good. Additionally the documentation is pretty thorough and easy enough to read from a Python point of view.
It's not only Python programmers who are interested in IronPython. In his blog, Mitch Barnett (a .NET programmer) talks about a new design tool he wants to build :
As a person that gets paid to architect and code in the Microsoft world, I have been following a nifty dynamic language called IronPython. In fact, I am really excited about IronPython as the .NET implementation is incredibly reflective, exactly what I need for the type of design tool I am talking about.
In another blog Shawn Fa raves about using IronPython for dynamic debugging of his .NET applications :
This is pretty powerful stuff -- I can easily see not wanting to run MDbg without the ability to lo PythonExt for anything but trivial debugging. Considering how easy it was to get this up and running, if you've got a decent object model to expose to users, embedding IronPython into your application really opens up new doors for your users to use your application in ways you might not have thought of (or didn't have time to implement yourself) -- yet makes their experience much better.
So how good is IronPython ? Well, other than occasional (minor) bugs we have had very few problems with IronPython. All the standard library we have used works. We use PyUnit for full unit tests.
There is currently a problem with accessing .NET attributes from IronPython. In the case of manipulating data-types sent to the clipboard this has forced us to resort to C#.
We have had good results using even quite large third party extension modules, like PLY.
At Resolver, performance wasn't the reason for choosing IronPython over CPython, it was because we wanted the .NET integration. However, we have seen some interesting speed-ups which we can only attribute to the .NET JIT compiler.
I think that several companies are going to use IronPython as a RAD tool for prototyping applications. When they appreciate how much easier it makes development, some of them will never make the jump back to C#.
IronPython is implemented on top of the .NET framework, rather than the Python VM. That means no Python stack frames, and no bytecode objects. So, for example, you can't pickle code objects. It may be possible to serialize compiled code objects using the dotnet serializer, but I haven't tried.
You can't use C extension modules from IronPython .
The os module doesn't have the start or system functions. There are very simple .NET process control techniques though (System.Diagnostics.Process). Some other platform specific commands (like os.fstat for example) may also be missing.
Other than that there are very few differences between IronPython and CPython.
There is a list charting the progress of IronPython in running the standard Python 2.4 regression test suite, over at Channel 9. Occasionally this list is up to date.
This article describes howto create applications with IronPython. With minor changes to the import semantics, it could probably also be used quite straightforwardly on Python for .NET.
Python for .NET is a version of CPython that integrates with the .NET framework. Brian Lloyd has recently changed the import semantics of Python.NET to use a clr in the same way that IronPython does. The aim is that programs written for IronPython will run unmodified on Python.NET.
Some of the Windows Forms API is available in Mono, so it may also run on that. Mono is cross platform, meaning you may still be able to create cross platform applications with IronPython.
Unfortunately, a key part of IronPython isn't yet available on the .NET compact framework. This means that IronPython won't run on PocketPC devices.
|||Unfortunately this affect modules like zlib, csv and Tkinter (etc), which are all written in C. Equivalent .NET assemblies exist for most of these. Additionally the PyPy project is causing pure python equivalents to be created for many C modules.|
For buying techie books, science fiction, computer hardware or the latest gadgets: visit The Voidspace Amazon Store.
Last edited Fri Nov 27 18:32:35 2009.