Python Programming, news on the Voidspace Python Projects and all things techie.
IronPython - Do You Need It?
On the subject of IronPython, Calvin Spealman worries about the possibility of fragmentation of the Python community. He goes so far as to say "IronPython's users are increasingly pushing IronPython-only recipes, libraries, and tutorials."
Firstly that ignores a massive amount of effort by the Microsoft team and the IronPython community (Seo Sanghyeon in particular) to ensure that IronPython maintains as much compatibility with CPython and the standard library as possible. When reading his entry it seemed to me that Calvin didn't understand that although IronPython doesn't ship with the Python standard library you can still use (most of) it. Simply set the environment variable IRONPYTHONPATH to include the location of your Python library directory. For copyright reasons  Microsoft won't ship the standard library, but they've put specific fixes into IronPython to address issues with it.
More importantly though, Calvin's entry kind of misses the point of IronPython. IronPython is more important for bringing .NET programmers to Python than it is for bringing Python programmers to .NET. If you don't need .NET then you probably don't need IronPython. And if you've got IronPython, you sure as hell want to know how to access .NET from inside it. If the IronPython community doesn't demonstrate how to do this then it will miss the audience it is most relevant to, and miss a huge opportunity.
That said, there are some good reasons for Python programmers to use IronPython. These include:
- Better support for multi-threading with multiple processors (CPython can't do this)
- Built-in security model with AppDomains (CPython can't do this out of the box, although Brett Cannon is working on a model and Zope does something interesting)
- Native Windows GUI (with a relatively sane API) via Windows Forms: better than any I've seen for CPython
- Access to third-party .NET components, especially sophisticated GUI components
- IronPython is much easier to extend with C# than CPython is with C
- IronPython (on .NET) may be an easier corporate sell
Despite that seeming like an impressive list, my guess is that it will leave most Python programmers unmoved.
IronPython is still good for Python, it raises the profile of Python. That doesn't mean you all need to use it...
I got into IronPython because a company who had already chosen .NET needed a scripting language and were so impressed with IronPython they decided to write their whole application with it. The more companies that do that the better. I've no intention of dropping CPython though, and when/if I come to write another desktop application it would probably be with CPython (but it will be a hard decision - we have a mighty fine test framework I could use and the GUI stuff is really very nice).
IronPython aside, there are two new and important issues facing the Python community.
The first of these is the 'problem' of Python 3. The Twisted developers have already declared that they have no current plans to port to Python 3 and my guess is that currently there are other major frameworks / projects in the same position (Zope ?).
The Python developers are aiming to make as much of Python 3 as possible available in Python 2.6. That means that it will at least be possible to write code that runs with minimal changes on Python 2.6 and Python 3. There will also be the 2to3 translator that should take care of a lot of other problems. The intention is that code that has been through the translator shouldn't need hand tweaking to run on Python 3. That way developers don't have to maintain two branches.
Some of the changes proposed are pretty heavy though, especially the changes to strings and to the I/O layer. I'm personally unconvinced that 'arbitrary' code will be able to make it through the 2to3 converter but it will be a great help. It doesn't address at all the issue of C extensions.
In the long run though I don't think this will matter. Even after Python 3 is stable, it's going to take a long time before the production userbase is anything like as large as the Python 2.X userbase. I suspect that over time this will sort itself out. A few projects may never make the jump, but that doesn't mean we should ditch this opportunity to improve Python. History will vindicate us.
The second issue is that of alternative implementations of Python. CPython is no longer alone. There at least five major implementations of Python now:
There is also CLPython which may or may not survive as a serious implementation.
Python is still unspecified as a language and CPython remains the 'reference implementation'. IronPython turned up various problems with the specification and at points there is no dividing line between implementation details and standard behaviour. I'm not saying that Python needs an ISO specification. For starters that wouldn't solve the problem. The problem isn't so much Python the language, it's all the millions of lines of Python code there are out there and that includes the standard library.
IronPython uncovered various places in the standard library that rely on unspecified behaviour or implementation details. For example, did you know that inspect.getargspec examines Python bytecode to retrieve the varargs and varkeywargs arguments to a function. That means that inspect.getargspec isn't available to IronPython and so help doesn't work.
There has been a lot of debate in the Python community as to what extent the standard library is a core part of Python the language. I guess to most developers they are inextricably intertwined, and that is probably right.
The PyPy project has already put some work, a lot of it through the Google summer of code, into providing pure-Python versions of C extensions. This is good news for IronPython and hopefully the other implementations.
I also hope that the experience of IronPython feeds back into CPython. In some cases this has already happened. The Python 2.4 documentation said that from __future__ import ... statements were only valid as the first statement in a module. This wasn't actually the case, and the IronPython team asked whether they should follow the spec or the actual behaviour of Python. This was fixed in Python 2.5.
Hopefully the Python community will respond to other issues raised by IronPython, PyPy and Jython and Python will continue to flourish in new and strange lands.
|||My guess as to their reason, but pretty likely to be right.|
This work is licensed under a Creative Commons Attribution-Share Alike 2.0 License.