- with statement available without future import
- New syntax for exception handling
- Class decorators
- hasattr not discarding all exceptions
- Being able to provide keyword arguments after *args
- Getter, setter and deleter on properties (damn useful)
- __dir__ support
Now that IronPython 2 is also out of the door, the team have been working on the 2.1 branch and implementing Python 2.6 features. Of course having IronPython 2.1 tracking Python 2.6 is a recipe for confusion, so Dave Fugate asked whether the new branch should be renamed IronPython 2.6:
I think the name for the next major release of IronPython might still be up in the air so to speak, but our developers have indeed started working on CPython 2.6 features. If you build the latest source drop from CodePlex, you should now be able to pass the '-X:Python26' flag to ipy.exe.Personally I agree that "IronPython 2.6" would be less confusing, and it is also the pattern followed by Jython for its version numbers.
Speaking of the next major release, do people prefer "IronPython 2.6" implying that we're targeting CPython 2.6 features or "IronPython 2.1" following the pattern we established with IP 1.1? My gut feeling is that IP 2.6 would cause less confusion...
Yesterday Dave Fugate posted this email to the IronPython mailing list:
Some of you may have noticed that IronPython bugs on CodePlex previously assigned to the “2.1” release are now assigned to “2.6”. We’ve simply renamed the 2.1 release of IronPython to 2.6 to reflect upon the fact that the next major release of IronPython will be largely compatible with CPython 2.6. All details about IP 2.1 that were previously discussed on Harry Pierson’s blog still apply to IP 2.6. We’re doing this simple name change to help eliminate confusion about IronPython’s compatibility with various CPython and Jython releases.Great news.
Dave also has another recent blog entry responding to another blog claiming that Sun hiring Jython developers and Microsoft developing IronPython is an attack on Python and free software: