IronPython and IronRuby: Four New Releases
There have been four new releases of IronPython and IronRuby; two new ones for each project.
The first pair of releases are for the CTP (Community Technology Preview) of .NET 4.0 Beta 1. Part of the Dynamic Language Runtime is included in .NET 4 and on top of this is built one of the major new features of C# 4.0 and VB.NET 10; the dynamic keyword. dynamic is a new static type and informs the compiler that operations on dynamic objects should be performed at runtime rather than bound at compile time. In particular this makes late bound COM and interacting with objects from DLR languages much more pleasant. It also enables true duck typing (in fact dynamic typing) in these traditionally statically compiled languages.
To go alongside the .NET 4.0 CTP are new releases of IronPython and IronRuby, targetting the same version of the DLR included the CTP.
More importantly (for those using IronPython and IronRuby) we have also had new released with new functionality. The IronPython release is the first beta of IronPython 2.6 and targets compatibility with Python 2.6. As well as new features from Python 2.6 it also includes important new features like ctypes and Python stack frame (sys._getframe) support.
The first pair of releases are for the CTP (Community Technology Preview) of .NET 4.0 Beta 1. Part of the Dynamic Language Runtime is included in .NET 4 and on top of this is built one of the major new features of C# 4.0 and VB.NET 10; the dynamic keyword. dynamic is a new static type and informs the compiler that operations on dynamic objects should be performed at runtime rather than bound at compile time. In particular this makes late bound COM and interacting with objects from DLR languages much more pleasant. It also enables true duck typing (in fact dynamic typing) in these traditionally statically compiled languages.
To go alongside the .NET 4.0 CTP are new releases of IronPython and IronRuby, targetting the same version of the DLR included the CTP.
This is our second preview of IronRuby running under the Dynamic Language Runtime that is built directly into a .NET 4.0 release! As before, this release allows you to use IronRuby objects and types as .NET 4.0 dynamic objects from within C# and Visual Basic code. These binaries are roughly equivalent to the functionality found in IronRuby 0.3. Please also note that the IronRuby CTP for .NET 4.0 Beta 1 will run only under .NET 4.0 Beta 1.
- IronPython 2.6 CTP for .NET 4.0 Beta 1 (Codeplex release page)
- Harry Pierson (DevHawk - IronPython PM) announces the release
- Dave Fugate (IronPython tester) also announces it
We’re quite pleased to announce the release of IronPython 2.6 CTP for .NET 4.0 Beta 1. This is our second preview of IronPython running under the Dynamic Language Runtime that is built directly into a .NET 4.0 release! As before, this release allows you to use IronPython objects and types as .NET 4.0 dynamic objects from within C# and Visual Basic code. While this release does share a bit in common with the upcoming IronPython 2.6 Beta 1 release (e.g., a number of MSI improvements), the core functionality is essentially that of IronPython 2.6 Alpha 1. Please also note that IronPython 2.6 CTP for .NET 4.0 Beta 1 will run only under .NET 4.0 Beta 1.
This walkthrough shows how the new Dynamic feature in C# 4.0 and Visual Basic 10.0 enables the natural use of object models that expect their host language to provide dynamic dispatch. This capability is demonstrated for an IronPython scenario of accessing libraries that are written for the Python language. Note that more advanced IronPython scenarios that involve hosting your own scripts with access to your application’s object model are beyond the scope of this walkthrough.
Notes:
- Using Dynamic with Office programming is demonstrated in the Office Programmability walkthrough.
- Using Dynamic with Silverlight will be shown in a later preview release of Visual Studio 2010.
More importantly (for those using IronPython and IronRuby) we have also had new released with new functionality. The IronPython release is the first beta of IronPython 2.6 and targets compatibility with Python 2.6. As well as new features from Python 2.6 it also includes important new features like ctypes and Python stack frame (sys._getframe) support.
Staying true to our "Conference-driven development schedule," this release is in conjunction with RailsConf '09, where IronRuby was demonstrated running real Rails applications and deploying them on IIS. A ton of work has been done in this release to get real Ruby programs running well, like RubyGems, Rake, Sinatra, and Rails.
We’re pleased to announce the release of IronPython 2.6 Beta 1. As you might imagine, this release is all about supporting new CPython 2.6 features such as the ‘bytes’ and ‘bytearray’ types (PEP 3112), decorators for classes (PEP 3129), advanced string formatting (PEP 3101), etc and as such includes nearly all of the new Python 2.6 features. The small number of remaining features will be implemented for Beta 2. The minimum .NET version required for this release is the same as IronPython 2.0; namely .NET 2.0 Service Pack 1.
There’ve also been several new features added: ctypes, sys.getframe, pyc for pre-compilation, and improved help. Ctypes provides access to C-based APIs and provides a way for Python developers to optimize performance or access libraries that would otherwise be unavailable. sys.getframe is commonly used by Python programs to introspect the call stack and can now be enabled with the –X:Frames and –X:FullFrames command line options; for better compatibility with programs that check for the presence of sys.getframe it is now not available unless these options are provided. The pyc.py pre-compiler is now shipped with IronPython and is available in the Tools\Scripts directory. Finally the help of many builtin functions and types has been improved by including IronPython.xml and IronPython.Modules.xml.
Another focus has been on improving startup time of large applications. This release accomplishes that through the adaptive compilation feature announced with 2.6 Alpha 1 and also includes many other enhancements to reduce the amount of code generation required to start applications. But only do these improvements help large applications but they also significantly speed up basic hello worlds startup time.
There’s also a few minor changes since IronPython 2.0.1 that are worth calling out here:
- Binaries are ngen’d for both 32-bit and 64-bit platforms on install by default
- IronPython.msi now offers a little more selection with respect to what you’d like to install. For example, Silverlight templates are optional
- The default installation location of IronPython.msi no longer indicates whether the 2.6 release is an Alpha, Beta, or a patched release. Future IronPython 2.6 installations will replace previous 2.6 releases which will be uninstalled automatically
- The -X:PreferComInteropAssembly flag has been removed. All COM interop is now done through normal COM dispatch
There are two big new features in this release. The first is our implementation of the ctypes module. The ctypes module is like P/Invoke for Python. It allows Python code to call into unmanaged DLL functions. Here, for example, I’m calling into the standard wprintf function from msvcrt.dll
IronPython 2.6 Beta 1 (2.6.0.10) on .NET 2.0.50727.4918
>>> import ctypes
>>> libc = ctypes.cdll.msvcrt
>>> ret = libc.wprintf("%s\n", "hello")
hello
Between ctypes and Ironclad, I think we’ll eventually be able to load most native Python extensions in IronPython. Woot!
The other big new feature in this release is a real implementation of sys._getframe. _getframe lets you write code that inspects the Python callstack.
IronPython 2.6 Beta 1 is the second IronPython release today! I'm happy to say that the sys._getframe issues of IronPython 2.6 Alpha 1 have been resolved, and we have re-added urllib.py and other modules dependent upon collections.py to the MSI installer. Man am I ever ready for the long weekend=)
Comments
Post a Comment