[IronPython] [ANN] IronPython 1.0 released today!

M. David Peterson xmlhacker at gmail.com
Tue Sep 5 23:05:12 CEST 2006


Congratulations, Jim!  Truly and amazing vision you and your development
staff have brought into fruition :)

>From my recent post to the O'Reilly Windows DevCenter,

ref:
http://www.oreillynet.com/windows/blog/2006/09/jim_huguninmsft_announce_ironp.html

Congratulations are in order to Jim Hugunin, Dino Viehland, Microsoft, the
> core IronPython development team<http://www.codeplex.com/Project/ProjectPeople.aspx?ProjectName=IronPython>,
> and two all of the community members that have been involved in the
> development of such a remarkable product which is represented by the final
> release of IronPython 1.0<http://www.codeplex.com/Wiki/View.aspx?ProjectName=IronPython>
> .
>
> To each of you listed above and to everyone involved with making this
> happen, a HUGE thank you! Truly an amazing accomplishment.
>


On 9/5/06, Jim Hugunin <Jim.Hugunin at microsoft.com> wrote:
>
> I'm extremely happy to announce that we have released IronPython 1.0today!
> 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)
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>



-- 
/M:D

M. David Peterson
http://mdavid.name | http://www.oreillynet.com/pub/au/2354
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060905/63766eea/attachment.html>


More information about the Ironpython-users mailing list