Wednesday, October 28, 2009

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).
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.
 An IronPython T-Shirt created by Harry Pierson. The text is C# + IPy = <3. You had me at "dynamic".
 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.
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).
 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.
 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! :-)

Tuesday, October 27, 2009

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.
(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:
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:
 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:
 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.

Monday, October 26, 2009

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.
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.
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.
 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.

Friday, October 23, 2009

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.
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.
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:
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:
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.  

Thursday, October 22, 2009

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.
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.
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:
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.
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.
 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.
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 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” = 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.

Monday, October 19, 2009

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.

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.
 

Saturday, October 17, 2009

A Good Mix 26: Winforms in Arabic, xbuild, Mono on Mandriva, Scheme and Poker

Still working through the large collection of IronPython and DLR related articles that I've discovered in the last few weeks. Only a few more to go.
 This is a translation of the Winforms with Mono and IronPython Tutorial Series into Arabic. It includes implementations of Snake and Tetris games as the final two parts of the tutorial showing how to create applications with IronPython on Mono or .NET.

A blog entry on new features in Mono 2.6 which has just had a preview release. Included in the release is xbuild, the Mono implementation of the MSBuild tool. xbuild is now compatible enough that it is capable of building IronPython and IronRuby.
This is a Japanese blog entry on using IronPython 2.0 with the Mandriva Linux distro. From the same blogger who has also blogged about IronEditor
We last covered IronScheme back in February when 1.0 Beta 2 was released. The project has moved on since then, with Beta 4 released in July. There have also been several status updates since then posted to the project page about progress in IronScheme.
A post from Greg Bray on using Resolver One and IronPython for writing poker applications:
Earlier this year I created a Monte Carlo Texas Holdem Simulator using an IronPython powered spreadsheet in Resolver One. The main goals were to learn IronPython, test how well it worked for creating complex spreadsheets, and enter a few of those spreadsheets into the Resolver One competition. Well I can honestly say that I exceeded even my own expectations on all three accounts, and it didn’t stop there either. After learning IronPython I started using it for the occasional random “Hey could you ...” tasks that get assigned to me at work, and I found a few other interesting uses for Resolver One as well.
A short InfoQ article on using Jimmy Schementi's repl-lib project to add an interactive interpreter to a .NET application.
Since Microsoft Dynamics is a closed-source application, Microsoft is turning elsewhere for examples of how dynamic languages can allow users to customize their experience. Once such example is Witty, an open source Twitter client.
A novel feature in Witty is that it includes a REPL console. Exposing the console is incredibly simple. Simply instantiate a ConsoleWindow object, pass in the objects you want your end-users to be able to access, and display it.

Lightweight Debugging for Hybrid C#/IronPython Apps

Harry Pierson, IronPython program manager for Microsoft, has written a series of posts on using a new feature in IronPython 2.6 to assist with debugging when embedding IronPython in .NET applications. The focus is not just on embedding for scripting, but actually using IronPython for polyglot programming - writing hybrid applications using both IronPython and C#.
 Seriously, let me introduce you to the worlds simplest Twitter application: GetThings. The app downloads a list of my tweets via the Twitter API and displays them in a list box. The UI is written in C# while the tweet download code is written in Python. Clearly, this is a pretty brain dead app – but the point isn’t to build a great Twitter app but rather to show how to use the settrace API from C#.

I’ve stuck the code up on GitHub. If you want to see the basic app in action sans debugging, start with the initial checkin. As you can see here, basic C# / IronPython integration is pretty trivial.
 Now that I’ve introduced my simple hybrid GetThings app, we need to set about adding support for debugging just the IronPython part of the app via the new lightweight debugging functionality we’re introducing in 2.6.

We saw last time how how easy it is to execute a Python script to configure a C# app – only four lines of code. If we want to support debugging, we need to add a fifth.
The DLR Hosting API has three distinct levels of functionality. As simple as this is, technically it’s level 2 since it’s using a ScriptEngine directly. If you wanted to use the simplest level 1 hosting API, you could use runtimes instead of engines and save a line of code.
I added traceback to my GetThings app in just two lines of code, but so far it doesn’t actually do anything that you would expect a debugger to do. But before we get to that, we need understand a little about how threading works for traceback debugging.

As I mentioned last time, the traceback debugger works by calling into the registered traceback handler at various times (entering/exiting a function, before executing a line of code and on exceptions). Execution of the Python code continues when the traceback function exits. That means that you have to block the execution thread while you let the user poke around with the debugger UI. For a console based app, that’s easy. For a GUI app, not so much.

At a minimum, you need to run your debugger UI on a separate thread from your main app window. If you want your main app window to be responsive while you debug, you’ll need to pump messages at a minimum (DoEvents in Windows Forms, similar approaches are available for WPF) or preferably run your python scripts on a background thread separate from either the main window UI thread or the debugger UI thread. To keep things simple, I’m going to simply block the main window thread while the debugger is active.
 In my last installment, I added support for a separate debug window on a separate thread from the main window thread. That way, I can pause the execution of the main window while the debug window stays responsive to user input. Now, let’s add some functionality to the debug window. I’m going to start by showing the source code of the python file being executed.

Tuesday, October 13, 2009

A Good Mix 25: The SharePoint Object Model, IronPython Tutorial, Crazy Snake and IronRuby

Yet another collection of IronPython and DLR related articles, projects and blog entries from the past few weeks.
 The iLove SharePoint blog recently posted an example of using the SharePoint object model from IronRuby. In the interests of balance he has posted the same example with IronPython.
 The AvbWiki, a Russian developer wiki, has put online several IronPython tutorial pages. It looks like it is mainly based on the tutorial that comes with IronPython 2, but could be a useful online reference on IronPython.
 Another release from the mysterious Japanese IronPython and Windows Forms project that we've covered before.
 This weekend I finally got around to downloading IronPython 2.6rc1 to test it against the upcoming builds of Mono 2.6 preview 1 (the version numbers matched, it felt right). Additionally in the land of Mono, I've been toying around with the IKVM project as of late, as a means of bringing some legacy Java code that I'm familiar with onto the CLR. As I poked in one xterm (urxvt actually) with IKVM and with IronPython in another, a lightbulb went off. What if I could mix different languages in the same runtime; wouldn't that just be cool as a cucumber? Turns out, it is.
 The last good mix collection included the release of SharpDevelop 3.1 (the Windows .NET IDE) and its support for IronPython. An alpha preview of an addin for IronRuby support has also now been released.
Support for IronRuby 0.9.1 is now available for SharpDevelop 3.1. The IronRuby addin is an early alpha preview release/proof of concept and is not an official part of SharpDevelop 3.1 so it is available as a separate download at the end of this post.

Features
  • Code folding
  • Syntax highlighting
  • File and project templates for Console and Windows Forms applications
  • IronRuby Console window
  • Windows Forms designer (limited)
  • C# and VB.NET code conversion to Ruby (limited)

Introduction to IronPython, Python for .NET Programmers and Dark Corners of IronPython

I've written three new articles on IronPython and put them up on my website. The first two are for developers new to Python or to IronPython whilst the third will be useful to anyone developing with IronPython whatever their programming background.
Just getting started with IronPython or wondering why you should be interested? This article introduces IronPython, explains how it came into existence and some of its more common use cases. The article also shows the basic IronPython and .NET integration with the interactive interpreter. The IronPython interactive interpreter is a great way to learn plus a useful tool for working with the .NET framework. The article even shows how the Dynamic Language Runtime allows languages to interoperate by using a Ruby library (through IronRuby) from IronPython.
An introduction to the Python programming language for programmers interested in IronPython. It covers the basic syntax and semantics and touches on how dynamic languages are different to statically typed languages. It also goes through the major programming styles possible with Python: interactive, scripting, procedural, functional, object oriented and metaprogramming.
The IronPython team have done a very good job of integrating Python and the .NET framework without having to change Python or introduce new syntax. Despite this there are various areas where you need to know some IronPython specific information; previous experience of Python or C# alone will not be enough.

This article contains a lot of the nitty gritty details of how to use Python the language to integrate with the underlying .NET framework.

A fourth article of mine has also gone online, although without any action - or even knowledge - on my part. An extract from chapter 8 of IronPython in Action has been posted to Developer Zone. This is the section on metaprogramming, introducing and explaining metaclasses in Python:

Monday, October 12, 2009

A Good Mix 24: Commerce Server 2009, SharpDevelop 3.1, NWSGI, PyCon India and more...

Another collection of blog entries and articles related to IronPython and the Dynamic Language Runtime.
A blog entry from Charles Medcoff with a nice example of writing product queries for Commerce Server 2009 (the Microsoft e-commerce platform) with IronPython, including the necessary app.config magic to get it to work.
SharpDevelop is a .NET IDE for Windows with excellent support for IronPython in its latest version. This release is the final version of 3.1, which includes the new IronPython support (including forms designer and debugger):
Seven months after the 3.0 release comes version 3.1 – the last feature release of the 3.x series. The following high-profile features were added to SharpDevelop:
  • IronPython Windows Forms Designer
  • Debugging Support for IronPython Applications
  • Profiler for Managed Applications
The Future: 3.1.x and 4.0
SharpDevelop 3.1 is a long-term stable release branch as we are switching to .NET Framework 4.0 with SharpDevelop 4.0 “Mirador”. When new third party releases like NUnit (that target .NET Framework 3.5) are released, we will provide point releases of SharpDevelop 3.1 that are tested against those third-party versions. General bug fixes will be included.

SharpDevelop 4.0 is currently in its Alpha stages – we won’t be releasing a Beta before .NET Framework 4.0 Beta 2 is available. Due to larger infrastructure changes, there are still quite a few areas of SharpDevelop 4.0 that don’t work at all.

A few things you will see in SharpDevelop 4.0: a rehostable text editor (dubbed AvalonEdit) written entirely in WPF, an Entity Data Model designer, more debugger goodness, WPF designer & XAML code completion, and more.

A new release of NWSGI by Jeff Hardy. NWSGI is a .NET implementation of the Python WSGI specification for IronPython; implemented as an ASP.NET HttpHandler for use with IIS 6 and 7. The goal is to allow you to serve WSGI web applications with IronPython and the IIS server. Notes on this release:
To coincide with IronPython 2.6 RC1, NWSGI 2.0 RC1 is now available. This release is identical to Beta 2, except for the version of IronPython is uses.
We covered the changes in NWSGI 2 previously.
Python conferences have exploded this year with new conferences all over the world. One of the new ones was PyCon India and it is good hear that IronPython featured there:
Second day, Mr. Keerthi Shankar Sekar gave a talk on ‘Python and .NET’, the talk was an introduction to IronPython – a Python interpreter for the Microsoft .NET platform. Mr Keethi gave a demo on setting up IronPython for application development and explained some of the major behind-the-scene differences between CPython and IronPython.
 Microsoft Agent is an API for manipulating odd animated cartoon characters in Windows. Unfortunately (I guess) Agent won't be developed any more. From the Agent homepage:
Microsoft has decided to discontinue development of Microsoft Agent technologies. Beginning with Windows® 7, Microsoft Agent will not be included or supported in future versions of the Microsoft Windows operating system. We encourage Microsoft Agent application developers and redistributors to evaluate their activities in light of this decision.
It is still fun to play with though, and this blog entry and snippet of IronPython shows you how to get an animated dog flying across your screen:
I was busy with some code and was trying to concentrate when I heard a noise from my computer that sounded like someone or something was scratching. My first impulse was to kill all the browser windows thinking that it must be some amateur website that had some flash ad running. Yet, 2-3 minutes later, something scratched yet again. And, there was this distinct feeling that this sound was quite familiar (no pun intended!)
At this point, I killed everything except my explorer windows. And, yet I could hear the scratching sound. And, that’s when it clicked. Mr. Rover – the ever friendly search assistant had completed the “fetch” and was waiting for me to do something with him again!
How can you not like the dog! Seeing Mr. Rover again, I was reminded of an IronPython talk that Mahesh Prakriya (from the DLR team) had conducted at MS IDC. One of his demos used to show how easy it was to invoke Merlin and make Merlin do some wizardry using IronPython.
Interest piqued, moments later, I had the latest build of IronPython downloaded and was ready to make Rover appear.

Friday, October 09, 2009

IronPython articles in English and Videos in Turkish

Ibrahim Kivanc is a Turkish blogger and programmer whose articles on Silverlight we have covered previously. He has now translated some of his articles on IronPython into English for us poor foreigners and created some screencasts in Turkish.
 As you know programming languages classified in two way; Dynamic Languages and Static Languages.

In some cases Dynamic Languages has many advantages rather then Static Languages. Python/IronPython and Ruby are Dynamic Languages; C#,Visual Basic are Static Languages.

Dynamic Languages that execute at runtime many common behaviors that other languages might perform during complication, if at all. These behaviors could include extension of the program, by adding new code, by extending objects and definitions, or by modifying the type system, all during program execution. These behaviors can be emulated in nearly any language of sufficient complexity, but dynamic languages provide direct tools to make use of them.
 Python + .NET, That takes the cake! Python runs on .NET… that sounds good.  Flexibility and easy coding of Python and powerful platform .NET together. Also on the great development enviroment of Visual Studio. This must be a dream :)

This news took me to my childhood year; Voltron cartoon! :) Powerful heroes  combined with shining then become most powerful hero, Voltron. IronPython sounds like Voltron :)
And the videos:
 IronPython Studio'ya daha yakindan bakmaya ne dersiniz?
 Bu videoda IronPython ile .NET kütüphanelerine erisime yakindan bakmaya ne dersiniz?

Try Python: Interactive Python Tutorial with Silverlight (and rst2xaml)

Silverlight is the Microsoft browser plugin runs on the Mac and Windows and in Safari, IE and Firefox browsers. As an added bonus it also supports IronPython, making it an ideal tool to build an interactive Python tutorial with.

Try Python is an open source project that takes the official Python tutorial and puts it alongside an interactive Python interpreter running in the browser. All of the code examples have a button to execute them in the interpreter, or you can just follow the tutorial trying out the examples yourself.
The Mono team are working on an implementation of Silverlight for Linux called Moonlight. The version capable of running IronPython code is Moonlight 2, but unfortunately the preview release can't yet run Try Python. Hopefully that will be fixed in the final release.

Try Python has the following features:
  • Auto-resizes with the browser
  • Navigation bar through the tutorial pages at the top and bottom
  • Individual pages are bookmarkable and the URL fragment auto-updates when you change page
  • Mouse scroll wheel supported over the tutorial and console scroll viewers
  • Control-C interrupts the running code with a keyboard interrupt
  • raw_input and input work in the interpreter
  • Basic auto-indent and auto-dedent in the console
  • Console history, including multiline history
  • Syntax highlighting in the console
  • reset command to clear the console
  • Assign to sys.ps1 and sys.ps2 from the console
There are various things still left to do, the project issues page tracks the ones I'm aware of. In particular, I've almost completed an implementation of the file type in pure Python, using browser local storage to actually store the files. This will allow the parts of the tutorial that teach file access to work in the browser. As the backend can be swapped out (for example to use a dictionary based storage) it could be useful to anyone wanting to unit test code that does file I/O (transparently swap out real file access for your tests). I'll blog about this once it is complete.

The Python tutorial is formatted using ReStructured Text, the popular text markup format implemented in Python. To render a nicely formatted version in Silverlight I've implemented a XAML writer for ReStructured Text and a XAML formatter for Pygments which does nice syntax highlighting of Python source code. XAML is the XML dialect for describing user interfaces in the WPF (Windows Presentation Foundation) and Silverlight user interfaces.

The XAML writer / formatter are in the rst2xaml project:
Try Python has already spawned at least one imitator. Try Powershell is a tutorial application for Powershell. It runs on the desktop with WPF and is inspiring me to create a desktop version of Try Python. rst2xaml can already output XAML for WPF and it could share a lot of code (but not all the code unfortunately) with the browser version, I just need to find the time...

Thursday, October 08, 2009

Distributing IronPython Packages: distutils, site-packages and PEP 370

The basic way of distributing and installing Python libraries (packages), and even scripts and applications, is with distutils which is part of the Python standard library.


A Python package consists of various source files and a setup.py script, which when executed at the command line installs the Python package into your site-packages folder. The typical invocation of a setup script is:
python setup.py install
site-packages is a directory created as part of a standard Python installation specifically to hold user installed Python packages (glossing over the difference between user and system installed packages for the purposes of this discussion).


Unfortunately distutils doesn't work with IronPython, for at least two reasons.

The second reason, the most easily dealt with, is that attempting to install a package with IronPython causes distutils to attempt to bytecode-compile the Python files; something destined to fail with IronPython.

C:\compile\test\foo-1.0>ipy.exe setup.py install
running install
running build
running build_py
running install_lib
copying build\lib\foo.py -> C:\Program Files\IronPython 2.6\Lib\site-packages
byte-compiling C:\Program Files\IronPython 2.6\Lib\site-packages\foo.py
to foo.pyc
Traceback (most recent call last):
 ...
ValueError: unmarshallable object
This is a bug in distutils that is easily remedied; under IronPython sys.dont_write_bytecode is True.

The first problem is that a normal installation attempt will fail like this:
C:\compile\test\foo-1.0>ipy.exe setup.py install
...

error: ...foo-1.0-py2.6.egg-info:  None
This is a permissions issue. The default install location for IronPython is "C:\Program Files\IronPython 2.6". Installing to this location requires elevated permissions and the site-packages folder it creates is not writable by non-admin users. If you run the same command from an elevated prompt (running with elevated permissions is the Windows equivalent of sudo) then it gets as far as failing with problem 2. The error message prompted by the "access denied" failure could certainly stand to be improved though.

CPython on Windows makes its site-packages folder writable by non-privileged users. This allows distutils to work its magic, but is also the cause of some of the odd behavior of easy_install; where it has to run a second cmd window with elevated privileges to actually install and this window flashes before your eyes not giving you time to read any error messages displayed. The solution is to elevate before running easy_install.

Even worse the CPython behaviour could be seen as a security issue. An untrusted user could create a sitecustomize.py that checks if the user is admin and installs malware. All the admin has to do is run Python and the code is executed with her priveleges.

It seems like the behavior of IronPython is correct and that CPython should change. Unfortunately that would mean the same access denied errors when installing packages unless done from an elevated command line (elevation of individual commands can also be done from the command line in a similar way to sudo but using runas).

There is fortunately a solution, both for CPython and for IronPython, in the form of PEP 370 per user site-packages folders that are new in Python 2.6.

If you install CPython 2.6 on Windows it creates a folder in the location: %APPDATA%\Python\Python26\site-packages. On my machine the full path is: C:\Users\michael\AppData\Roaming\Python\Python26\site-packages.

This is put on the path by site.py when you run Python and as it is a user directory it doesn't require elevation to install there. You install into the user directory rather than the 'usual' location with:
python setup.py --user install
Herein lies another problem though. IronPython uses the standard Python site.py, meaning that currently it shares the user site-packages folder with CPython. This is not ideal as typically you will want separate libraries installed for IronPython. When Jython ports to Python 2.6 it will have the same issue.

The best solution would be for site.py in Python 2.6 to have a compatibility fix applied where it conditionally adds an implementation specific folder to the path instead. distutils would also need to be aware of this so that when the --user flag is used packages are installed into the correct location. It would be a nice touch if --user could be the default in IronPython, but this isn't essential.

In Python 2.7 the sys module could grow a new attribute, perhaps sys.usersitepackagespath, so that the logic to set the right location can be moved out of site.py and distutils and back into the core implementations. (Antoine Pitrou has kindly volunteered to do this if it is acceptable to the other core-devs.)

UPDATE:  Christian Heimes, the author of PEP 370, is suggesting that sys.vm (or similar) should hold the name of the implementation and be used by site.py and distutils to determine the location of the user site-packages folder.

As a further step, the holy grail of managing IronPython packages will be getting Distribute (the successor to setuptools which is now essentially unmaintained) to run on IronPython. The maintainer of both Distribute and distutils is Tarek Ziade who is not only doing an awesome job but also very open to working on IronPython compatibility if he has help. One stumbling block is that Distribute (like its predecessor) is not yet PEP-370-aware, but this will be fixed in due course. Other stumbling blocks are the lack of zipfile and subprocess standard library modules in IronPython. Both of these require C extension modules not available for IronPython. The IronPython team will (at some point) get round to these, but in the meantime there are open source alternative implementations that Distribute could ship for use only on IronPython.

I'm sure there are plenty more issues, both big and small, but none are insurmountable. The goal, easily achievable, is to have quality package management tools that can be used across all the major implementations of Python.

I have filed a Python issue for the distutils problem and will work with Tarek and the other Python devs on the other compatibility issues I've discussed here.

Monday, October 05, 2009

Using IronPython as a Scripting Engine

IronPython makes adding Python scripting to .NET applications very simple. .NET applications interact with Python code through the DLR hosting API which is easy to use once you get used to the basic principles. You can find a guide to working with the DLR hosting API in IronPython in Action or my series of articles and examples on embedding IronPython.

A blogger called rune has been experimenting with embedding IronPython in C# business applications.
In this post I will look into the subject of extending an application written in a traditional .NET language like C# using IronPython. I am not talking about authoring assemblies by writing them in IronPython, though: I’m talking about letting some third party create plug-ins in Python which my application will load and execute at runtime.

Let’s say we are C# programmers developing some LOB application for processing orders from a fixed set of customers. Since these are trusted customers, they all receive special treatment: Some receive a discount on all their orders, for others we want to always add a “URGENT”-headline to their order, and yet others receive other kinds of special treatment.

Even if no third party will ever be creating plug-ins for our application, the support for plug-ins will greatly increase the application’s flexibility and reduce our maintenance costs.
To enable our order processing system to accomodate these and future cases, we have considered various options:
  • Implement all cases directly in the system using a lot of if-then-else and switches. When requirements are added or changed we implement, test and redeploy the application.
  • Implement a set of (parameterized) templates for handling cases like those described above. When requirements are added or changed, pray that they can be covered by one or more of the existing templates. Otherwise, implement a new template, test and redeploy the application.
  • Allow the application to execute plug-ins at certain stages in the process. Make the plug-ins execute in a sandboxed environment, thereby restricting the amount of havoc they can cause. When requirements are added or change, write a new snippet of code, test just the snippet (as opposed to the whole application) and deploy it.
Obviously, this post will explore the third option, using IronPython as an embedded scripting engine. I will not be presenting an implementation of the imagined order processing application but only showing code snippets illustrating the points of interacting with IronPython from C#.

So, the first thing to do is to be able to execute Python code from a C# application. This isn’t as difficult as it might sound...
In my last post, I gave an example of how to execute a Python script from within a C# application and I tried to justify why you might want to do something like that. In this post I will elaborate on the very simple example from the previous post by passing data to and from the Python script being executed. If you haven’t read the previous post, you should at least skim it.

The data we will be passing to IronPython will represent an order in an order processing application. To this end I have created two very simple classes...

Pumping Iron in Denmark and on Channel 9

Harry Pierson, IronPython program manager, has now returned in triumph from his world tour. The world tour included a series of talks at Danish universities and the Copenhagen .NET user group.
 At each of these universities, I did two talks. The first was Pumping Iron: The State of Dynamic Languages on the .NET Framework. That’s the one in the Channel 9 video. The other talk was Developing with the DLR, which I’ve posted to my Skydrive. That talk was more focused on the CLR and DLR as a platform for language development. If there’s interest (leave a comment), I’ll record audio for that presentation and post it up on SlideShare or something like that.
If you aren't prepared to take Harry's word that it went well, here is a blog entry from Allan Juhl Petersen who attended one of the presentations:
I had the pleasure of attending Harry Piersons TechTalk at Microsoft Development Center Copenhagen (MDCC) on IronPython.
IronPython is a new member of the .NET family, based on the programming language Python. The Iron part has become known as It-Runs-On-.NET.
 A video of the presentation is up on Channel 9:
As is commonly known, Microsoft is developing IronPython and IronRuby, .NET implementations of the popular open-source programming languages Python and Ruby.

While it is clear that Microsoft wants to attract existing Python and Ruby developers to .NET, the role of IronPython and IronRuby for existing .NET developers is less clear. What value is there for a .NET developer in learning IronPython? What are the tradeoffs between IronRuby and a more traditional .NET language like C# or VB? Harry Pierson, new PM for IronPython, will discuss where dynamic . languages fit in the.NET developers toolbox.
Whilst browsing Channel 9 I discovered another DLR related video that I'd not seen before. This is an interview with Kevin Hazzard, who has featured several times on this blog:
In this interview Kevin Hazzard, C# MVP based in Richmond, Virginia, discusses with Zhiming Xue dynamic languages like Python and Ruby, the Dynamic Language Runtime (DLR) from Microsoft and the next generation of C# that’s becoming a dynamic language.  He explains that the DLR as “the language of languages” defines the boundaries between languages and what’s required for those languages to interoperate with each other and that the DLR as a centerpiece of the .NET Framework 4.0 provides a dynamic dispatch mechanism that elegantly addresses the interoperability problems that we've been working hard to solve since the days of RPC and COM.

Sunday, October 04, 2009

IronPython 2.6 and the Roadmap Beyond

The IronPython team just released IronPython 2.6 Release Candidate 1.

Since the release there have been a few changes and a few bug reports so there will be another release candidate before the final release.

Harry Pierson, IronPython Program Manager, has done two blog entries discussing what is in the new release and the roadmap for IronPython beyond the 2.6 release.
As I’ve written before on this blog, this is a HUGE release for us:
  • Python 2.6 features such as with statement, class decorators and byte literals
  • Adaptive Compilation
  • __clrtype__ Metaclasses
  • ctypes and frames support
  • Lightweight Debugging
  • 417 bugs fixed!
Anyway, with 2.6 winding down, the IronPython team finds ourselves in a unique position that we’ve never been in before: caught up. As far as I can tell, most of the Python community hasn’t made the move to Python 3.1 and Python 2.7 is looking like it will be released next summer. So IronPython is caught up with the latest version of Python most of the Python community appears to be using.

So that begs the question: what do we do now?

Of course, we want to hear from you regarding our next steps, but some things we are looking at include...
It’s not quite out the door yet, but things have gotten quieter around here since we shipped the Release Candidate of 2.6. But there’s no rest for the dynamic, so we’ve already started thinking about what we do next.

Since we shipped 2.0 last December, we’ve shipped two service releases: 2.0.1 two months later in February and 2.0.2 four months after that in June. We weren’t planning on doing a 2.0.3 release, but then we discovered the CLR folks made a breaking change to partial trust in Windows 7. David recently emailed the IronPython mailing list looking for feedback on other must-fix bugs we can get to for 2.0.3. If you’ve got an opinion on 2.0.3 must-fix bugs, please respond to that thread.

...

At this point, we’ve got the next few months mapped out, but not much more beyond that. Specifically, we have two gaping holes in the roadmap:
  • Visual Studio Integration
  • IronPython 3.x
For now, I’m going to leave these holes unfilled. Currently, the rest of my VS Languages teammates (along with the rest of DevDiv) are heads down driving towards beta 2 of Visual Studio 2010. Once they reach that milestone, planning on Visual Studio v.next will begin. Those plans have the potential for impacting how the IronPython team proceeds going forward.

If you have opinions about how IronPython should move forward then leave a comment on either of these blog posts.

Friday, October 02, 2009

Teaching IronPython D520: Week 6

Tony Andrew Meyer is teaching IronPython as course D520 ("Programming") at Northtec in New Zealand, using IronPython in Action as course material.

 He's been posting regular updates on how the course is going, including his course notes. We last covered weeks four and five and now we're onto week 6.
Chapter 6 of IronPython in Action covers “properties, dialogs, and Visual Studio”.  This seemed an obvious place to insert the material on user-interface design that is normally covered in the course, and to look a bit more deeply than the textbook does at Visual Studio itself (and the Windows Forms controls and their properties).  I only scheduled a single week to cover this, but I suspected that it might take more than one (I left an empty slot in the schedule to cover one such over-run), and that was, indeed, the case.  The students received notes [PDF], slightly longer this week (covering the UI design material not in the textbook, as well as the usual chapter summary, key points, and examples, and the steps required to install IronPython support in the ‘Experimental Hive’ Visual Studio SDK), and a fairly simple lab exercise. 
It's really interesting, and slightly scary, to see the work I put in on the book describing details like properties and the observer pattern actually being used to teach programming.

As often happens, real life has caught up on Tony's blogging. He is still putting the weekly notes together but has got a bit behind. He promises more notes coming soon.

Gestalt and Python and Ruby in HTML Script Tags

Gestalt is a project that uses Silverlight to allow the browser to be scripted with Python and Ruby in exactly the same way as you script it with Javascript - using the HTML <script> tag.

Jimmy Schementi has been working on the dynamic languages Silverlight integration, as outlined in his back to just text paper. He has begun the work he describes there and it is almost feature complete. It is all publicly accessible in a github repository (download zip-file).

You can see it in action in some great examples of what is possible with gestalt (very pretty) in the samples that Jimmy has ported over:
Jimmy is also looking for feedback on the code:
If you find any bugs, please report them on MY FORK's Issues tab (I wanted to use GitHub's issue tracking a little ... eventually I'll move them over to CodePlex when it gets checked in):
http://github.com/jschementi/ironruby/issues

I'd like feedback on the code also, so feel free to code-review the commits so-far to enable this. They are in chronological order, so you can just click each link in order, and please leave your comments in the commit's "Comments" section at the bottom of each page...