QCon Presentation: Real World IronPython

In March I spoke at the  QCon London 2009 conference on "Real World IronPython". InfoQ has just put up a video of the presentation, including the slides and a demo of "Resolver One", the highly programmable spreadsheet system created by Resolver Systems with IronPython.

• Real World IronPython

Summary
Michael Foord discusses IronPython, the DLR, dynamic languages on .Net, static vs. dynamic typing, Visual Studio integration, Resolver One, Intellipad, Crack.net, embedding IronPython, the ScriptEngine, error handling, dynamic operations, functions as delegates, and the C# 4.0 dynamic keyword.

Bio
Michael Foord works full time with IronPython for Resolver Systems; creating a highly programmable spreadsheet called Resolver One. He has been using IronPython since about version 0.7, and has been developing with Python since 2002. He blogs and writes about Python and IronPython far more than is healthy for one individual and in 2008 was made the first Microsoft MVP for dynamic languages.

About the conference
QCon is a conference that is organized by the community, for the community.The result is a high quality conference experience where a tremendous amount of attention and investment has gone into having the best content on the most important topics presented by the leaders in our community. QCon is designed with the technical depth and enterprise focus of interest to technical team leads, architects, and project managers.

A Good Mix 28: NTornado, WPF, Testing in Italian, More Benchmarking, and adodbapi

Yet another collection of IronPython and DLR related articles, projects and blog entries from the past few weeks.

• NTornado

NTornado is an IronPython version of the Tornando web server. The Tornado Web Server is the open source version of the non-blocking web server that power FriendFeed and now part of the Facebook's open source initiative. This server is coded in Python and with strong emphasis on operating systems with epoll support.

NTornado is a port of Tornado to IronPython using asynchronous high-performance sockets in .NET. To run the demos (requires IronPython 2.6):

> ipy -X:Frames "demo file name".py

• Getting WPF Control Template in IronPython

I always find myself needing a control template so I can customize one of the WPF controls. I used to fire up Expression Blend to get it, and then realized I could write a little IronPython code to do it. Paste this code into the IronPython 2.0 or 2.6 console to see it work!

• Modulo .NET test con IronPython

 A translation of James McCaffrey's article on testing .NET code with IronPython into Italian, for the MSDN magazine.

• Pyevolve benchmark on different Python flavors

Pyevolve aims to be a  "complete genetic algorithm framework written in pure python". The Pyevolve blog has benchmarked some genetic algorithms code running on all the major Python implementations: CPython 2.6 & 2.5, Unladen Swallow, IronPython, PyPy and Jython. IronPython 2.6 comes out slower than CPython (and Unladen Swallow) and faster than PyPy and Jython.

• adodbapi works with IronPython 2.6

adodbapi is a Python module for working with Microsoft ADO for connecting to databases and datasources. adodbapi is compatible with the Python DB-API 2.0 specification, meaning that it can be used by any DB-API compatible code. Thanks to the work of Vernon Cole, adodbapi now passes all tests when run on both CPython and IronPython.

The Dynamic Languages Team

A blog entry from Lisa Feigenbaum (the Microsoft Visual Studio Languages Community Program Manager) introduces us to all the members of the IronPython and IronRuby development teams and the MVPs (community members).

• Connecting with IronPython & IronRuby Team Members

IronRuby: website, mailing list
IronPython website, mailing list

In the blog post you can find details of all the team members, including links to their blogs and twitter accounts.

Team members:

• Jim Deville (IronRuby)
  
• Jimmy Schementi (program manager for dynamic languages Silverlight integration)
• Harry Pierson (IronPython program manager - but not for much longer)
• Dave Fugate (IronPython testing and release infrastructure guy)
• Dino Veihland (IronPython)
• Tomas Matousek (IronRuby I *think*)
• Shri Borde (the man in charge)
• David Dicatio (IronPython)

Missing from this list is John Lam (IronRuby program manager) and Curt Hagenlocher who was an IronPython developer but may now be working on a secret project...

The blog post also lists the Microsoft MVPs (Most Valued Professionals) who are community members recognised for their contributions.

• Michael Foord (IronPython)
• Jeff Hardy (IronPython)
• Sarah Dutkiewicz (IronPython)
• Michael Letterle (IronRuby)
• Ivan Porto Carrero (IronRuby)
  

A Good Mix 27: A Dynamic T-Shirt, Testoob, Mathematica and Blaze

Yet another collection of IronPython and DLR related articles, projects and blog entries from the past few weeks.

• You had me at dynamic

 An IronPython T-Shirt created by Harry Pierson. The text is C# + IPy = <3. You had me at "dynamic".

• Testoob 1.15 Released
• Testoob Project Homepage

 The latest release of the Testoob project (yet-another-Python-testing-framework) announces IronPython support. I haven't used Testoob, but it is nice to see more projects supporting IronPython:

Testoob is an advanced testing framework and test runner for Python. As a test runner, it can run your unittest test suites and make your test-running easy with tons of useful options. As a framework, you can use it to make your test-writing easy with even more useful options.

Version 1.15 (Oct. 2009) adds better Python 2.6, IronPython, and Jython support, as well as test coverage improvements, better color support, and some new options and bugfixes.

• BoxHeadRoom: IronPython and Mathematica

For interactive experimentation, particularly in the scientific and mathematical fields, a big competitor to Python is Mathematica.

A Japanese blogger has created an interactive shell (using IronPython - mathform.py) for working with the Mathematica Player. This is a continuation of his article on using Mathematica with IronPython which is short but links to several other resources on the topic (also in Japanese).

• BLAZE SMART LAUNCHER – UNIQUE DESKTOP EXPERIENCE

 A review of Blaze, the IronPython desktop automator. The review is mostly positive and includes a list of suggestions for further improvements, including a couple of enhancements for the IronPython scripting integrations:

• Allow Blaze Assistant to export suggested automations to IronPython scripts. 
• Enhance Blaze integration with IronPython. Currently, the first time a script is run takes quite a while.

• Experimenting with IronPython

 A report from another developer who has been having fun experimenting with IronPython. Mike Hansford is also finding the IronPython integration in the SharpDevelop IDE helpful:

When I get completely jaded with Visual Studio and C# / VB, I’m discovering that SharpDevelop and IronPython make not only a refreshing change but really help with making progress when I’m building out a sticky piece of code. Previously, I’d open a fresh project in C# in Visual Studio and go from there. It’s OK, but switching to a dynamic language that is C-like has been great. SharpDevelop even has a console with (hallelujah!) Intelli-Sense! :-)

Working with .NET Code Remotely with execnet

Testing is a big topic in Python, with major libraries like py.test and nose pushing forward the state of the art. Even the standard library module unittest has had a lot of improvements that will appear in Python 2.7 and 3.2.

Part of py.test is a library for distributed testing and deployment with remote Python interpreters. This library is called execnet:

The execnet package allows you to:

• instantiate local/remote Python Interpreters
• send code for execution to one or many Interpreters
• send and receive data through channels

execnet performs zero-install bootstrapping into other interpreters; package installation is only required at the initiating side. execnet enables interoperation between CPython 2.4-3.1, Jython 2.5.1, PyPy 1.1 and IronPython and works well on Windows, Linux and OSX systems.

Support of Jython and IronPython are experimental at this point. Feedback and help with testing welcome.

The IronPython support allows you to remotely work with .NET objects / libraries from CPython.

• Working with C# objects from CPython

(Experimental) use your CPython interpreter to connect to a IronPython interpreter which can work with C# classes. Here is an example for instantiating a CLR Array instance and sending back its representation:

import execnet
gw = execnet.PopenGateway("ipy")

channel = gw.remote_exec("""
    import clr
    clr.AddReference("System")
    from System import Array
    array = Array[float]([1,2])
    channel.send(str(array))
""")
print (channel.receive())

using Mono 2.0 and IronPython-1.1 this will print on the CPython side:

System.Double[](1.0, 2.0)

Using IronPython needs more testing, likely newer versions will work better. please feedback if you have information.

IronPython 2.6 Release Candidate 2 and news from DevHawk land

A new release candidate for IronPython 2.6 has just been released. This is the third release in under a week for the IronPython team, following on from the releases of IronPython 2.0.3 and and IronPython 2.6 for .NET 4.0 Beta 2.


IronPython 2.6 is (or will be) a big release. The major feature is compatibility with Python 2.6, but there are a whole host of others features as well:

• The __clrtype__ metaclass for data binding and .NET attribute support
• Implementation of the ctypes module
• Support for Python stack frames and sys.settrace, which means the pdb debugger works
• Better performance through adaptive compilation
• Faster startup

The new release:

• IronPython 2.6 Release Candidate 2
• Performance Comparison of IronPython 2.6 RC2 and Python 2.6
  

We’re pleased to announce the release of IronPython 2.6 Release Candidate 2.  Since the public availability of Release Candidate 1, we’ve addressed the following:

• The “json” CPython package has been included with our MSI installer
• CPython’s logging module can be utilized without passing the –X:Frames command-line parameter to ipy.exe
• Documentation distributed with the release has been updated
• A memory leak in the hosting APIs reported on the mailing list was fixed
• Multi-threaded debugging using sys.settrace show now work
• Fixed mapping of .NET “Compare” methods to __cmp__ when they return the wrong type
• The imp.load_module function now respects the file argument
• A bug related to relative module imports has been addressed
• Fixed indexing on .NET types defining DefaultMemberAttribute
• Several issues involving new-style string formatting have been corrected
  

If no major issues with this release candidate are discovered, we hope to ship the final 2.6 release in a little under a month.  Anyone planning on upgrading to 2.6 should try out this release candidate and let us know of any issues you find ASAP.

Harry Pierson, the IronPython program manager for Microsoft has just announced that he is leaving the IronPython team for the Windows team:

• Joining Windows

 Big news in DevHawk land: I’ll be taking on a new role in the Windows division after I come back from TechEd Europe (plus a week vacation visiting my bro-in-law in Germany after TechEd).

You guys have heard of Windows, right? They just released a new version recently you might be aware of…

Of course, starting a new job means my time on the IronPython team is coming to an end. As excited as I am about this new opportunity in the Windows division, I’m a little sad to be leaving Developer Division and the IronPython team. I’ve joked with audiences that I care about Python because Microsoft pays me to care about Python, but that’s not completely true. Python is a fantastic language and IronPython’s combination of Python + .NET is hard to beat in my opinion. IronPython has made significant progress while I’ve been here the last eighteen months – two major releases (well, 2.6 is almost done), redisting the Python standard library, Visual Studio 2010 compat - but there’s still much for IronPython to accomplish. And of course, leaving behind such great teammates like Dino, Dave, Jim and Jimmy is ALWAYS hard.

Harry has also blogged about the latest two of the three IronPython releases:

• IronPython 2.0.3 and 2.6 RC2

 It has been a very busy week for the IronPython team. Just under a week ago, we shipped a CTP for .NET Framework 4.0. Since then, we’ve shipped two – yes, two! – more versions of IronPython. Three releases in one week! If we could keep up that pace, we’d be shipping like 27 more releases of IronPython by the end of the year!

FYI, we’re not going to keep up the pace of shipping three releases a week for the next two months. We may be a little crazy on the IronPython team, but we’re not THAT crazy!

Actually, all three of these releases represent fairly small changes in the IronPython source tree. The .NET 4.0 beta was a CTP, so it’s basically whatever we had in our main trunk when they forked .NET Framework for the beta.

IronPython 2.0.3 is a minor point release in the 2.0 branch (duh). In addition to backporting some fixes from 2.6, we had to fix an CLR breaking change in partial trust on Windows 7. If you’re using IronPython 2.0.x in partial trust on Windows 7 you *MUST* upgrade to 2.0.3 (or 2.6 when it’s released). Sorry about that – but it was out of our hands.

IronPython 2.6 RC2 is – as you would expect - a minor update over the first release candidate. There was a memory leak discovered in the hosting APIs which forced us to do a second release candidate. Since we had to fix that, we took in a few of other fixes including some standard library changes (we left out json by accident in RC1 and Michael Foord got logging updated to work better with IronPython so we took the latest version of it). As per the release notes, we expect this to be the final RC and will re-ship it as RTM in about a month. Please start using this latest release and let us know if you find anything.

Improvements to Try Python: File I/O

Try Python is an online Python tutorial that has an interactive interpreter running in the browser through the magic of Silverlight and IronPython.

Try Python presents the Python tutorial, with executable code examples for you to try out. However, because Silverlight is a sandboxed browser plugin, with no access to the local filesystem, the parts of the tutorial that do file I/O didn't work.

I've fixed that by reimplementing the file type (and swapping out the builtin file type and open function) in pure Python using local browser storage to store files. You can now create files from the interpreter and read them back in in exactly the same way you do in standard Python on the desktop.

This pure Python implementation of file also has other potential uses, for example unit testing filesystem access.

• Testable file Type and File I/O in Try Python

A few weeks ago I announced Try Python, a Python tutorial with interactive interpreter that runs in the browser using IronPython and Silverlight.

Because it runs in Silverlight, which is sandboxed from the local system, the parts of the tutorial that show how to do file I/O didn't work. I've finally fixed this with a pretty-much-complete implementation of the file type and open function that use local browser storage (IsolatedStorage) to store the files.

You can try this out by going direct to the Reading and Writing Files part of the tutorial (page 32).

The implementation is split into two parts, the file type and open function in storage.py and the backend that uses the IsolatedStorage API in storage_backend.py. There are also extensive tests of course.

• Testing File Access with storage.py

So in my last blog entry I introduced storage.py and discussed how it could simply testing file access. What I didn't do is show you how.

In writing this example I realised an added benefit; it can remove the differences between platforms.

Python on .NET: PyPy-cli-jit

PyPy is the combination of an interpreter compiler toolchain that allows you to write interpreters (Virtual Machines really) in a static subset of Python, called RPython, along with an implementation of Python in RPython.

The compiler toolchain allows you to compile your interpreters for several backends. The major backends are native code, for the JVM and for the CLI (which is .NET and Mono). This allows you to maintain a single codebase and produce an interpreter that runs on all these platforms. The PyPy .NET backend is called pypy-cli.

PyPy on its own runs at somewhere between the same speed as CPython and twice as slow. Because it has better garbage collection (PyPy doesn't use reference counting) there are some things it does faster but there are also places it is slower.

There are various cool things about PyPy, for example it is already useful where you want a sandboxed Python interpreter. The really cool thing, and perhaps one of the driving forces for creating PyPy, is the JIT compiler that aims to provide a radical performance improvement over standard Python.

The JIT has gone through several experimental versions, causing many in the Python community to lose hope that it will ever live up to expectations, but the latest version has proved viable. It is gradually being integrated with the compiler toolchain and expanded to cover more of the Python language. The PyPy team have posted a series of blog entries demonstrating the power of the JIT.

The clever thing about the JIT is that because of the way it works it is even useful for the backends that also have their own JIT, like the JVM and .NET. The JIT is able to generate statically typed bytecode for performing operations with known types, allowing operations that don't use the dynamic features of Python (which are typically only used in a small proportion of Python code) to run very fast. The JVM and .NET backends of PyPy are therefore 'double-JITted'. The JIT emits bytecode which is then compiled to native code by the platform JIT (the PyPy JIT for the native backend directly emits assembler).

A recent blog entry gives some performance metrics for the JIT on the CLI backend (pypy-cli-jit) including comparisons with IronPython on both .NET and Mono. The result: pypy-cli-jit is between half the speed of IronPython up to five times faster depending on the operation. As the PyPy JIT improves so will these numbers.

• First pypy-cli-jit benchmarks

 As the readers of this blog already know, I've been working on porting the JIT to CLI/.NET for the last months. Now that it's finally possible to get a working pypy-cli-jit, it's time to do some benchmarks.

Warning: as usual, all of this has to be considered to be a alpha version: don't be surprised if you get a crash when trying to run pypy-cli-jit. Of course, things are improving very quickly so it should become more and more stable as days pass.

For this time, I decided to run four benchmarks. Note that for all of them we run the main function once in advance, to let the JIT recoginizing the hot loops and emitting the corresponding code. Thus, the results reported do not include the time spent by the JIT compiler itself, but give a good measure of how good is the code generated by the JIT. At this point in time, I know that the CLI JIT backend spends way too much time compiling stuff, but this issue will be fixed soon.

 What PyPy-cli doesn't yet have that IronPython has is the close integration with the .NET framework. Whilst there is some support (you can use some framework classes) the current focus is on getting the JIT to work. It will be quite some time before pypy-cli is a viable alternative to IronPython, or even useful in a practical sense for anything, but it is still good to see progress.

IronWatin: mind the gap

WatiN is a .NET automated web testing tool inspired by the Ruby tool Watir. R. Tyler Ballance has been working on IronPython integration for WatiN, based on the Python unittest testing library (of which I am particularly a fan) and designed to be as 'pythonic' as possible.

• IronWatin: mind the gap 
• IronWatin Project Home on GitHub 

Last week @admc, despite being a big proponent of Windmill, needed to use WatiN for a change. WatiN has the distinct capability of being able to work with Internet Explorer's HTTPS support as well as frames, a requirement for the task at hand. As adorable as it was to watch @admc, a child of the dynamic language revolution, struggle with writing in C# with Visual Studio and the daunting "Windows development stack," the prospect of a language shift at Slide towards C# on Windows is almost laughable. Since Slide is a Python shop, IronPython became the obvious choice.

Out of an hour or so of "extreme programming" which mostly entailed Adam watching as I wrote IronPython in his Windows VM, IronWatin was born. IronWatin itself is a very simple test runner that hooks into Python's "unittest" for creating integration tests with WatiN in a familiar environment.

I intended IronWatin to be as easy as possible for "native Python" developers, by abstracting out updates to sys.path to include the Python standard lib (adds the standard locations for Python 2.5/2.6 on Windows) as well as adding WatiN.Core.dll via clr.AddReference() so developers can simply import IronWatin; import WatiN.Core and they're ready to start writing integration tests. When using IronWatin, you create test classes that subclass from IronWatin.BrowserTest which takes care of setting up a browser (WatiN.Core.IE/WatiN.Core.FireFox) instance to a specified URL, this leaves your runTest() method to actually execute the core of your test case.

IronPython 2.0.3 (and uninstalling IronPython for .NET 4 Beta 1)

As always the IronPython team aren't content with one new release, but have pushed out another as well.

While IronPython 2.6 gets closer to its final release there is still life in IronPython 2.0. A new bugfix version, 2.0.3, has just been released.

• IronPython Release 2.0.3 

Note: this version of IronPython is for .NET Framework 2.0 SP1, 3.0 and 3.5. If you want a version of IronPython to work on .NET Framework 4.0 with C# 4.0's new "dynamic" keyword, you need a compatible version of IronPython.

IronPython 2.0.3 is a minor update to IronPython 2.0.2 and the latest in a series of CPython 2.5-compatible releases running on the .NET platform. Again, our priority was to make IronPython 2.0.3 a bugfix release that remains backwards-compatible with IronPython 2.0.2. In particular, we focused on issues the IronPython community brought to our attention through CodePlex. As such, there have been important improvements on the compatibility and stability of IronPython as summarized below.

Silverlight users: As of IronPython 2.0.2, a new version of Silverlight, namely Silverlight 3, is required to build the “Silverlight Release” and “Silverlight Debug” configurations of IronPython.sln. Please update Silverlight accordingly if you intend to do so.

The following issues were fixed:

• 24224 – UTF-8 encoding sometimes broken!
• 19510 – Need to recognize DefaultMemberAttribute for getitem/setitem
• 24129 – 2.0.3: not should not be 1
• 21976 – 2.0.3: Executables created by Pyc.py broken without access to original Python sources
• 24452 – 2.0: Fix FxCop warnings
• 24453 – 2.0: Cannot build “FxCop” build configuration of IronPython.Modules.csproj
• 24571 – 2.0.3: help(Array[Int32]) causes a traceback
• 24373 – empty sys.argv in compiled scripts for 2.0
• 24475 – Creating a low-permission version of PythonEngine fails post 2.0.0
• An issue where sys.argv lacks its first argument (the executable name) in compiled scripts
• A failure in partial trust on Windows 7 due to a SecurityException.

To go with the new release their is a new performance page showing how IronPython 2.0.3 compares with Python 2.5 on various benchmarks:

• IronPython Performance Report: IronPython 2.0.3

After the release of IronPython 2.6 for .NET 4.0 Beta 2 a few users reported problems uninstalling IronPython for .NET 4.0 Beta 1. This is because this version of IronPython depends on .NET 4.0 Beta 1, so is you uninstall .NET 4 first then the uninstaller for IronPython won't run!

This is a pain in the *ss, but Dave Fugate has come to the rescue with instructions on how to do a manual uninstall:

• Uninstalling "IronPython 2.6 CTP for .NET 4.0 Beta 1" without .NET 4.0 Beta 1 Installed

We've heard from a few people in the last week that they're having trouble uninstalling our community technology preview of IronPython running under .NET 4.0 Beta 1 if the installation of .NET 4.0 Beta 1 has been removed or replaced in some fashion.  Basically what's going on is that a prerequisite for running IronPython.msi (whether you intend on installing/repairing/removing it) is the presence of a very specific version of .NET - namely v4.0.20506.  The tie in to this .NET 4.0 release means that even with an install of .NET 4.0 Beta 2, you'll be unable to remove the IronPython CTP for Beta 1 cleanly unless you also have .NET 4.0 Beta 1 installed concurrently (is this even possible I wonder...).

There's at least one alternative to removing "IronPython 2.6 CTP for .NET 4.0 Beta 1" if you no longer have access to .NET 4.0 Beta 1 on your machine.  Basically you'll just need to remove the related installation directory and shortcut menus by hand.  Also, there's those pesky registry entries that don't have to be removed, but can be if you prefer.  

IronPython and IronRuby for .NET 4.0 Beta 2

If you're part of the Python community then it may well have passed you by that a major new release of the .NET framework is imminent. .NET 4.0 is a new version of the Common Language Runtime (CLR), unlike 3.0 and 3.5 which were primarily new libraries and language enhancements for C# and VB.NET.

A big part of .NET 4.0 is the Dynamic Language Runtime (DLR), on which IronPython and IronRuby are both built, and parts of the DLR are moving into the core .NET. This enables the introduction of the dynamic keyword in C# 4.0 and VB.NET 10.

One of the major use cases for the dynamic keyword is to make it easier to integrate dynamic languages with the statically typed ones, for embedding or for hybrid applications.

A minor addendum to the new .NET 4.0 is Visual Studio 2010. .NET 4.0 Beta 2 is the second beta (Community Technology Preview - CTP) of both .NET 4.0 and Visual Studio 2010. To go with this CTP there are new releases of both IronPython and IronRuby.

• IronPython 2.6 CTP for .NET 4.0 Beta 2

We’re quite pleased to announce the release of "IronPython 2.6 CTP for .NET 4.0 Beta 2". This is our third 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. This release is extremely similar to IronPython 2.6 RC 1. Please also note that "IronPython 2.6 CTP for .NET 4.0 Beta 2" will run only under .NET 4.0 Beta 2.

To try out this preview release:

1. Install some variant of .NET 4.0 Beta 2 or Visual Studio 2010 Beta 2.
2. Install IronPython 2.6 CTP for .NET 4.0 Beta 2.msi
3. Follow any of the many dynamic walkthroughs online. Dynamic programming in VB.NET 10 and C# 4.0 would be a good start.

• IronRuby CTP for .NET 4.0 Beta 2

We’re pleased to announce the release of the IronRuby CTP for .NET 4.0 Beta 2. This is our third 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.9. Please also note that the IronRuby CTP for .NET 4.0 Beta 2 will run only under .NET 4.0 Beta 2.

This release also includes includes the binaries for the IronPython 2.6 CTP for .NET 4.0 Beta 2.

Interesting that the IronRuby guys are pleased, whereas the IronPython guys are only quite pleased...

Another interesting fact is that with a release of IronPython and IronRuby built on the same version of the DLR you can use it to create applications that embed both Ruby and Python or to interoperate directly between the two languages (hybrid applications written in both Python and Ruby and sharing libraries and objects).

Harry Pierson and Jimmy Schementi have blogged about these new releases:

• IronPython and IronRuby CTPs for .NET 4.0 Beta 2 

In case you’ve been hiding under a rock (or maybe just aren’t tracking developments in the .NET community outside of IronPython), Microsoft released Visual Studio 2010 beta 2 this week. Of course for me personally, the most important feature in Visual Studio 2010 is C# 4.0 new dynamic type (also available in Visual Basic, but since VB already supported some level of late binding it’s not exactly “new” to VB).

For those of you who want to experiment with this cool new feature, may I present IronPython 2.6 CTP for .NET 4.0 Beta 2. If you can’t think of any cool things to try with this new feature, the VB team blog has some scenarios to get your started.

• IronRuby and IronPython for .NET 4.0 Beta 2

I’m pleased to announce the release of the IronRuby and IronPython CTPs for .NET 4.0 Beta 2. This is the third preview of IronRuby and IronPython running under the Dynamic Language Runtime that is built directly into .NET 4.0. 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.9 and IronPython 2.6 RC. Take a look at Harry Pierson’s blogpost about this release as well, especially if you’re more into snakes than gemstones.

Articles by Ibrahim: IronPython Console, ASP.NET, Visual Studio and readmee.com

Ibrahim is the Turkish blogger whose posts and articles on IronPython that we've featured before. He has published several more articles in English on working with IronPython and one article in Turkish.

• IronPython Console

 In this article we take a deep look at IronPython Interactive Console. We will see some basics of Python and IronPython to become acquainted with the IronPython environment.

IronPython interactive interpreter console is the easiest way to start using IronPython.  We can easily explore whole IronPython world which is include ironpython modules, .Net libraries and Python Built-in’s. For IronPython starters it’s great way to exploring .Net Libraries. We can use IronPython Interactive Interpreter for start to developing WinForms, COM objects, WPF, XNA, Embeding C#, Silverlight… projects.

• Asp.NET with IronPython Integration

One of the IronPython development area is Asp.NET. In this article we will see Visual Studio 2008 Asp.Net integration.
First check out the features of Asp.NET here and ASP.NET Dynamic Language Support.

Then download the Asp.NET IronPython integration for visual Studio 2008 installer here.

Asp.NET with IronPython is really rocks! This combination gives us time/performance advantage. Especially in small scripts for events, python code is too short and powerful! So we can prototype projects quickly.

Because of Dynamic Language, it will work server-side on client’s machine and it works dynamicly. With this feature we can connect websites faster.

• IronPython Studio & VS Integration

IronPython Studio Installation & Visual Studio 2008 Integration

IronPython Studio is a development IDE for developing IronPython projects based on Visual Studio. It’s like developing web application IDE "Visual Web Developer 2008 Express" for a specific development area. Built on Visual Studio and it’s free.

First of all you shouldn’t install ironpython studio setup directly. You must install some pre-requisites. If you try to install directly after that you get an error “Cannot find one or more components. Please reinstall the application”.

You should first install Visual Studio 2008 Shell setup. It is available for Visual Studio 2008 Shell, Isolated and Integrated modes. You can install isolated mode from here about 380MB. After the installation open it from installed directory.

• IRONPYTHON (This is the Turkish article.)

“IronPython” = Python + .NET

Merhabalar, bu makalem Readmee dergisindeki ilk yazım oldu. Umarım bu güzel dergide makale serimle sizlerle birlikte olur ve her ay buradan IronPython maceralarımı sizlerle paylaşırım.

Öncelikle kendimi tanıtayım. Ben İbrahim KIVANÇ. Erciyes Üniversitesi Bilgisayar Mühendisliği 4. Sınıf öğrencisiyim. 2 yıldır üniversitemde Microsoft Student Partner olarak görev almaktayım. IronPython projesine hem makale hem de yerelleştirme olarak yardımcı olmaktayım.

Sheldon: A WPF IronPython Console Control

Sheldon is a Windows Presentation Foundation (WPF, the Windows user interface library that is part of .NET 3) component for embedding an interactive interpreter into a .NET application.

Embedding IronPython is one of the core use cases for IronPython and whilst I have seen several Windows Forms Console components, but this is one of the first reusable WPF one I'm aware of.

• Sheldon: A WPF IronPython Console Control
• Sheldon Project Subversion Repository

This sample was created to pitch an idea to a client about enabling a macro system in their application. Users might be able to make use of functions like OpenAccount("ACME"), ExecuteJob("SalesForecast2009"), and so on. Using the Command Pattern, commands could be written to an Output window in the application while the user uses the UI - that could be used as a learning tool for learning the command line.