On behalf of all of us at Resolver, congratulations! Many thanks to everyone on the IP team for making such a great product.
All the best for future releases. Giles -- Giles Thomas Resolver Systems [EMAIL PROTECTED] Jim Hugunin 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@lists.ironpython.com >http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > _______________________________________________ users mailing list users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
