I'm extremely happy to announce that we have released IronPython 1.0 today!
 http://www.codeplex.com/IronPython

I started work on IronPython almost 3 years ago.  My initial motivation for the 
project was to understand all of the reports that I read on the web claiming 
that the Common Language Runtime (CLR) was a terrible platform for Python and 
other dynamic languages.  I was surprised to read these reports because I knew 
that the JVM was an acceptable platform for these languages.  About 9 years ago 
I'd built an implementation of Python that ran on the JVM originally called 
JPython and later shortened to Jython.  This implementation ran a little slower 
than the native C-based implementation of Python (CPython), but it was easily 
fast enough and stable enough for production use - testified to by the large 
number of Java projects that incorporate Jython today.

I wanted to understand how Microsoft could have screwed up so badly that the 
CLR was a worse platform for dynamic languages than the JVM.  My plan was to 
take a couple of weeks to build a prototype implementation of Python on the CLR 
and then to use that work to write a short pithy article called, "Why the CLR 
is a terrible platform for dynamic languages".  My plans quickly changed as I 
worked on the prototype, because I found that Python could run extremely well 
on the CLR - in many cases noticeably faster than the C-based implementation.  
For the standard pystone benchmark, IronPython on the CLR was about 1.7x faster 
than the C-based implementation.

The more time I spent working on IronPython and with the CLR, the more excited 
I became about its potential to finally deliver on the vision of a single 
common platform for a broad range of languages.  At that same time, I was 
invited to come out to Microsoft to present IronPython and to talk with members 
of the CLR team about technical issues that I was running into.  I had a great 
time that day working through these issues with a group of really smart people 
who all had a deep understanding of virtual machines and language 
implementation.  After much reflection, I decided to join the CLR team at 
Microsoft where I could work with the platform to make it an even better target 
for dynamic languages and be able to have interesting technical discussions 
like that every day.

The first few months at Microsoft were a challenge as I learned what was 
involved in working at a large company.  However, once the initial hurdle was 
over I started experiencing the things that motivated me to come here in the 
first place.  The team working on dynamic languages in general and IronPython 
in particular began to grow and I got to have those great technical discussions 
again about both how to make IronPython as good as it could be and how to make 
the CLR an even better platform.  We began to take advantage of the great new 
features for dynamic languages already shipping in .NET 2.0 such as 
DynamicMethods, blindingly fast delegates and a new generics system that was 
seamlessly integrated with the existing reflection infrastructure.

We were also able to release IronPython publicly from Microsoft with a 
BSD-style license.  In the agile spirit of the project, we put out a new 
release of IronPython once every three weeks (on average) over the course of 
the project.  This helped us connect well with our daring early adopters and 
receive and incorporate their feedback to make IronPython better.  We've had 
countless excellent discussions on the mailing list on everything from 
supporting value types to calling overloaded methods.  Without the drive and 
input of our users, IronPython would be a much weaker project.

IronPython is about bringing together two worlds.  The key value in IronPython 
is that it is both a true implementation of Python and is seamlessly integrated 
with the .NET platform.  Most features were easy and natural choices where the 
language and the platform fit together with almost no work.  However, there 
were challenges from the obvious cases like exception type hierarchies to the 
somewhat esoteric challenges concerning different methods on strings. We spent 
long days and sometimes weeks looking for the best answers to these challenging 
problems and in the end I think that we have stayed true to both Python and 
.NET.

To drive our Python compatibility, we run a large portion of the standard 
Python regression test suite in addition to a large custom test suite we added 
that runs IronPython and CPython side-by-side to test for identical behavior 
whenever possible.  Despite all of this work, there will still be differences 
between IronPython 1.0 and CPython.  The most obvious difference is that 
IronPython is missing a number of standard C-based extension modules so things 
like "import bsddb" will fail.  We maintain a detailed list of differences 
between the two implementations and aim to reduce the size of this list in 
every release.

IronPython has also striven for deep integration with the CLR.  For the 
implementation this is a great thing as it lets us take advantage of 
highly-tuned components developed for other languages such as the just-in-time 
compiler, garbage collector, debugging support, reflection, dynamic loading and 
more.  This integration is also valuable to IronPython developers as it lets 
them easily use any and all libraries built for .NET from their Python code.

This is the 1.0 release of IronPython.  It's more complete and well tested than 
any other 1.0 product I have personally released in my career.  However, like 
any other software product it's not perfect.  You can search for known issues 
and let us know about any new ones that you find in our public bug database.  
We're continuing to work on IronPython and we want your input on how to make 
1.1 and future releases even better.

It's been an exciting journey for me to see IronPython go from a rough 
prototype playing around with some ideas to a solid 1.0 release.  This never 
could have happened without all the people who've contributed to this project 
along the way.  My thanks go out to all the users who braved our early releases 
and passed along their problems and suggestions.  My thanks also go out to the 
amazing group of people here at Microsoft who've come to join this project and 
drive it to this quality 1.0 release.

Shipping IronPython 1.0 isn't the end of the road, but rather the beginning.  
Not only will we continue to drive IronPython forward but we're also looking at 
the bigger picture to make all dynamic languages deeply integrated with the 
.NET platform and with technologies and products built on top of it.  I'm 
excited about how far we've come, but even more excited by what the future 
holds!

Thanks - Jim Hugunin (for the IronPython Team)
-- 
http://mail.python.org/mailman/listinfo/python-list

Reply via email to