[IronPython] [ANN] IronPython 1.0 released today!

[Charlie Moad]

I got it once, but tried again and it went away.

On 9/6/06, Tim Riley <riltim at gmail.com> wrote:
> I keep getting an error from codeplex when I try to download 1.0.bin. Am I
> the only one?
>
>
> On 9/5/06, Jim Hugunin < Jim.Hugunin at microsoft.com> wrote:
> > 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)
> > _______________________________________________
> > users mailing list
> > users at lists.ironpython.com
> >
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> >
>
>
> _______________________________________________
> users mailing list
> users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
>