Another Awesome Collection - IronPython Links

A selection of IronPython and Dynamic Language Runtime related web pages and blog entries.

• Getting Started with IronPython

John Cook makes a start with IronPython. This means using one of the three distributions available from the Codeplex homepage: the source code, the prebuilt binaries or the msi installer.

• IronPython is a One Way Gate

Having got started John Cook is disappointed that he can't use Python C extensions from IronPython, and finds it hard to call into IronPython from C#.

The answer to the latter problem is to use the IronPython hosting API, and John Cook has written another blog post on the former problem which will get an IronPython-URLs entry all of its own.

• NaroCAD to have support for IronPython 2.0!

This seems like an exciting announcement, but is short on links to find further information. The upshot is that NaroCAD has, or will shortly have, support for scripting it with IronPython 2 and possible IronRuby as well:

This means that with minimal change right now NaroCad will support in the same way any DLR capable language (like IronRuby).

What can you do right now with the IronPython integration?

• You may execute IronPython commands like this "Hello world" program:
• clr.AddReference("System.Windows.Forms")
• from System.Windows.Forms import *
• MessageBox.Show("hello from NaroCad")
• You may: execute the lines you write, load a file from disk, or save onto a disk your hard worked program
• Pressing "Enter" to any line will execute your line of program, and in case the program will misbehave the exception will be shown to the user
• You can change all the properties of the command line editor like this: panel.CommandLineEditor.ShowLineNumbers = 1; or anything that reflects the CommandLineView public members (so you can hide/show the items in real time). The way to react with NaroCad internal API is a subject of change but this is a fully working concept
• The editor use the file: commandLineHistory.py (or create a blank one if none exists), as the editor default text.

• IronPython Exception: [A]Person cannot be cast to [B]Person

Darrell Hawley, who has recently been experimenting with IronPython and nose, had difficulties when experimenting with the IronPython hosting API. If you add a reference to one set of assemblies in your C# project (and use the classes they contain), but add a reference to a different copy of the same assembly in the IronPython part of your project, then you are going to get odd errors (and odder error messages)!

You can avoid these problems altogether by adding the reference to the hosted IronPython runtime programattically from C# (instead of calling clr.AddReference from IronPython):

Assembly assembly = typeof(CSharpClass.Person).Assembly;
runtime.LoadAssembly(assembly);

• Probando IronPython 2
• IronPython Pyc
  

A pair of Argentinian blog entries by the same author, which I think bewails various problems that the writer had with IronPython 2 - specifically startup time and compiling to binary with the Pyc IronPython compiler.

Unfortunately he is correct. IronPython startup time, especially when importing a lot of Python modules, is not great. There are workarounds, and one of them is compiling your application and dependent modules to binary using Pyc (the writer reports a 30% improvement for importing the Cheetah package).

The writer had been led to believe that this process was transparent to your application which isn't quite the case:

• To import from compiled assemblies you need to add references to them first
• You have to manually add references to System.dll and mscorlib.dll which you don't have to do with IronPython scripts. This should be fixed in a future release of Pyc.
  
• Another bug in Pyc means that if you compile scripts to executables then sys.argv may not be correctly populated with command line arguments (oops!).

At Resolver Systems we compile and deploy a large application using Pyc. We don't use Pyc for the main executable, but instead have a custom executable that embeds IronPython and launches the application.

Whilst there are bugs, the authors rant in the second entry that IronPython compilation isn't identical to CPython bytecode compilation is a little misplaced. Import performance on the other hand is something that the IronPython developers do need to focus on. Thankfully they say that they are addressing this, and that we will reap the benefits of this in IronPython 2.6.

• Excel Formulas and the DLR - Part 1

Chris Cavanagh wants to implement an expression language, similar to the formula language in Excel, using Dynamic Expression Trees. Expression Trees are used to represent Asbract Syntax Trees (AST) in dynamic languages built on the DLR, but it looks like Chris has managed to parse expressions and generate charts without actually using the DLR. The promised part 2 hasn't yet followed, but hopefully soon...

UPDATE: In a comment Chris points out that part 1 does use the DLR to evaluate expressions, and that part 2 is now up!

• CodeHTMLer Language Definition for Python

A short entry from Harry Pierson with a syntax highlighting definition for Python for CodeHTMLer. CodeHTMLer is a simple program that translates plain text code into a colorized HTML version of the code, useful for posting code examples to a blog. Harry also has a language definition for F#, a statically typed functional programming language for .NET.