IronPython 2.0.1 Released
IronPython 2.0.1 is a minor update to IronPython 2.0 which in turn is a CPython 2.5 compatible release running on the .NET platform.
The top priority for this release was improving upon performance while retaining backwards compatibility with IronPython 2.0. One of many notable areas we’ve improved upon is that float-integer comparisons are now 74% faster than they were in 2.0. A full report documenting changes in interpreter performance from 2.0 to 2.0.1 can be found at: Comparing IronPython 2 and 2.0.1 Performance
A special thanks goes out to Resolver Systems for helping us in identifying areas needing performance improvements.
You can download the new release from:
In addition to numerous bug fixes in our IronPython 2.6 branch that were backported to 2.0.1, we also fixed the following CodePlex bugs specifically for this release:
The top priority for this release was improving upon performance while retaining backwards compatibility with IronPython 2.0. One of many notable areas we’ve improved upon is that float-integer comparisons are now 74% faster than they were in 2.0. A full report documenting changes in interpreter performance from 2.0 to 2.0.1 can be found at: Comparing IronPython 2 and 2.0.1 Performance
A special thanks goes out to Resolver Systems for helping us in identifying areas needing performance improvements.
You can download the new release from:
In addition to numerous bug fixes in our IronPython 2.6 branch that were backported to 2.0.1, we also fixed the following CodePlex bugs specifically for this release:
- 20632: can't write a __len__ returning a uint
- 20492: TupleExpression.IsExpandable is internal, should be public
- 20605: Compiling with pyc and PySerial module
- 20616: wrong TypeError message when invoking str.join: implicit parameter 'self' not counted
- 20623: InitializeModule needs to add refs to mscorlib/System
IronPython newbie, but... when I install 2.0.1 from MSI file, the install folder name includes the full version number 2.0.1, but both the startup info line and sys.version say 2.0.0, as does the file properties dialog. Any way to check that I really do have 2.0.1?
ReplyDeleteThere was a recent post from Dino saying that the assembly version hadn't changed so that this could be a drop in replacement. The file version did change - so you should be able to compare these to check you have the right version.
ReplyDeleteIf you lookup the thread on the IronPython mailing list archives (I think it was a reply to the release announcement) then you should be able to get the details.
Thanks, that's helpful. Now that I know they are not updating assembly version, I'll assume that I have the correct files. But the difficulty that I have with your suggestion (comparing file versions) is that I have nothing to compare to... I find nowhere online or off that says what the file version should be. At a minimum I would think that it should be in the readme for the version, and on the project's download page (and I'll post a suggestion to that effect). But since the file version that I have is the same (2.0.20209.0) as the IP distributed with the newest Resolver One beta, I'm hopeful that it's correct!
ReplyDeleteFor the record, here's the post you refer to:
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Dino Viehland
Sent: Friday, February 13, 2009 3:32 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Announcing IronPython 2.0.1
We're actually following the example of the CLR and other managed libraries here not something from dynamic languages :). Minor non-breaking releases are in-place upgrades - for example you don't have mscorlib at version 2.0.50727.42, mscorlib at version 2.0.50727.3521 and a ton of versions in between - you just have mscorlib at the version it shipped at in 2005 which is 2.0.50727.42. But it's file version changes with every patch so you can determine exactly what version you have. And it's the same w/ all of the other framework DLLs as well. So for major versions I agree with you - managing policy files is a way of life, but for minor versions not reving the assembly version is also a way of life.
As for concerns of breaking changes... The 2.0 branch is locked down and only sees targeted changes that are explicitly back ported. This is different from the major releases and the betas where there was active development which can and does alter APIs. So we do maintain a high bar of compatibility between these point releases. It's also what we've done with all the 1.x.y point releases as well so there isn't some new precedent here.
We could switch to updating the assembly version between minor versions but I'd like to have evidence that we are indeed breaking things first. We have been more liberal than the frameworks (allowing signature changes in modules because they shouldn't be called directly from C#) but we haven't been hearing about problems to date.