[ANN] IronPython 1.0 released today!
Jim Hugunin
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)
Méta-MCI
Michel Claveau
Sybren Stuvel
> I'm extremely happy to announce that we have released IronPython 1.0
> today! http://www.codeplex.com/IronPython
Congratulations!
> We were also able to release IronPython publicly from Microsoft with
> a BSD-style license. [...] Without the drive and input of our users,
> IronPython would be a much weaker project.
I hope they take your example to heart and start releasing more Open
Source code.
Sybren
--
Sybren Stüvel
Stüvel IT - http://www.stuvel.eu/
Neal Becker
san...@gmail.com
> Will it run with mono?
Yes, it will run with Mono 1.1.17 or later out of the box with zero
problems.
sk...@pobox.com
sanxiyn> Yes, it will run with Mono 1.1.17 or later out of the box with
sanxiyn> zero problems.
For those of us who have never used IronPython or Mono, is there a quick
start document laying about somewhere? It wasn't clear to me where to even
look. For example, is Mono == DotGnu?
(I'm on Mac OS X in case that matters.)
Thx,
Skip
Ray
> I'm extremely happy to announce that we have released IronPython 1.0 today!
> http://www.codeplex.com/IronPython
<snip>
> Thanks - Jim Hugunin (for the IronPython Team)
Congratulations!!!! I've been following IronPython too since you
announced it years back--it's really exciting to hear this, can't wait
to get home to download and play with it! :)
Kudos!
Ray
san...@gmail.com
>
> For those of us who have never used IronPython or Mono, is there a quick
> start document laying about somewhere? It wasn't clear to me where to even
> look. For example, is Mono == DotGnu?
I scribbled a rough howto. Hope it help.
Mono and DotGNU are two different projects, with similar goals.
gslin...@gmail.com
> I'm extremely happy to announce that we have released IronPython 1.0 today!
> http://www.codeplex.com/IronPython
Way to go, Jim!! I am impressed with the effort.
--greg
Chris
> I'm extremely happy to announce that we have released IronPython 1.0 today!
> http://www.codeplex.com/IronPython
<snip>
I'm no code guru but it sounds interesting. So can I import numpy,
scipy, matplotlib, wxpython etc like I do now with CPython and expect,
short of a few tweaks, that my code will work? At work we seem to be
doing more and more with dotNet and perhaps this is a way of bringing my
tools into the same environment.
In any event, what you've done sounds cool.
Chris
Noel...@gmx.net
;o)
But I'm a little bit concerned. Have you ever thought of using a
different file prefix for python files depending on .NET assemblies
like .pyi? Sooner or later we want to associate IronPython files with
IronPython in the windows shell. Don't get me wrong, I really
appreciate your effort of bringing Python to .NET. But I fear a lof of
users could be disappointed if they start a IronPython file with
CPython and vice versa.
Just my €0.05,
Noel
Neil Hodgson
> I'm no code guru but it sounds interesting. So can I import numpy,
> scipy, matplotlib, wxpython etc like I do now with CPython and expect,
> short of a few tweaks, that my code will work?
No, IronPython is currently unable to load CPython DLLs.
Neil
Diez B. Roggisch
No, you can't. I'm not sure if there are any bridging attempts being made,
but in this respect IronPython is the same as Jython - a completely
different runtime which executes its own byte-code.
Diez
Super Spinner
BTW, here's a John Udell screencast of Jim demo'ing IronPython. Among
other things, it shows IronPython integrating with Visual Studio,
Monad, C#, VB.NET, and WPF. It's a great video.
http://weblog.infoworld.com/udell/2006/08/30.html#a1515
Chris
> Chris wrote:
>
>> Jim Hugunin wrote:
>>> I'm extremely happy to announce that we have released IronPython 1.0
>>> today!
>>> http://www.codeplex.com/IronPython
>> <snip>
>>
>> I'm no code guru but it sounds interesting. So can I import numpy,
>> scipy, matplotlib, wxpython etc like I do now with CPython and expect,
>> short of a few tweaks, that my code will work?
> No, you can't. I'm not sure if there are any bridging attempts being made,
> but in this respect IronPython is the same as Jython - a completely
> different runtime which executes its own byte-code.
>
> Diez
the wealth of additional packages that, by association, come to be
considered part of "python". Anyway thanks for saving me from some
fruitless explorations.
Felipe Almeida Lessa
> I'm extremely happy to announce that we have released IronPython 1.0 today!
> http://www.codeplex.com/IronPython
Does IronPython runs Twisted?
--
Felipe.
Aahz
Jim Hugunin <Jim.H...@microsoft.com> wrote:
>
>I'm extremely happy to announce that we have released IronPython 1.0 today!
> http://www.codeplex.com/IronPython
Congrats!
--
Aahz (aa...@pythoncraft.com) <*> http://www.pythoncraft.com/
I support the RKAB
Lawrence Oluyede
> Does IronPython runs Twisted?
I really don't think so. They don't have many needed modules, like
select :-)
--
Lawrence - http://www.oluyede.org/blog
"Nothing is more dangerous than an idea
if it's the only one you have" - E. A. Chartier
Duncan Booth
> Felipe Almeida Lessa <felipe...@gmail.com> wrote:
>> Does IronPython runs Twisted?
>
> I really don't think so. They don't have many needed modules, like
> select :-)
>
So? IronPython has a select module although it doesn't seem to be complete
yet. The IronPython mailing list has discussions about getting CherryPy to
run, and it sounds as though it isn't quite there yet, but it is getting
there.
Lawrence Oluyede
> So? IronPython has a select module although it doesn't seem to be complete
> yet. The IronPython mailing list has discussions about getting CherryPy to
> run, and it sounds as though it isn't quite there yet, but it is getting
> there.
I don't think my answer is wrong. He asked if Twisted runs on IronPython
and as a matter of fact it doesn't. Everything can happen in the future
Diez B. Roggisch
They do have some c-modules, in the core. For example some portmapping.
I'm not fluent in that subject, so I can't judge the .net-portability of
that, nor the importance for twisted in general.
Diez
John J. Lee
[...re Scipy on IronPython...]
> No, you can't. I'm not sure if there are any bridging attempts being made,
> but in this respect IronPython is the same as Jython - a completely
> different runtime which executes its own byte-code.
Haven't heard re Scipy &co specifically (I'd be very impressed if they
were even thinking about it), but I heard somebody was implementing
the ctypes API for IronPython.
John
Luis M. González
People are already porting some of these libraries.
Those that are written in pure python don't need to be ported, but
those that rely on c extensions can be rewritten in c# or any other
.NET language.
Felipe Almeida Lessa
> People are already porting some of these libraries.
> Those that are written in pure python don't need to be ported, but
> those that rely on c extensions can be rewritten in c# or any other
> .NET language.
Or in C that is P/Invoked from the CLR, although this option is
somewhat less portable. See
http://www.mono-project.com/Interop_with_Native_Libraries
--
Felipe.