Tuesday, December 30, 2008

End of Year Selection

A few months ago I got behind on posting interesting IronPython related links. I've caught up a lot, but a whole bunch of interesting stuff happened in November and December that I haven't reported yet.

Some of that will have to wait for another day, but we'll end the year with a selection of some of the snippets from the last couple of months.

IronPython Cookbook


A couple of new recipes in the IronPython Cookbook, by Davy Mitchell and Atif Aziz:
  • Process Monitor - demonstrates how to write a small utility in IronPython that monitors a process and re-launches it if it dies.
  • How to Play a Wav - this short example plays a WAV format sound file using System.Media.SoundPlayer.
Speech Synthesis in IronPython

Another short example of how to use IronPython to make your computer speak like a robot:
Other Assortments

Sunday, December 28, 2008

Pumping Iron: Dynamic Languages on .NET

The esteemed Mr Tartley recently stepped into the shoes of Harry Pierson (Microsoft IronPython PM) and spoke about dynamic languages on the .NET framework at the Øredev conference in Malmö, Sweden.


He has posted the slides and notes online, based on Harry's presentation but delivered with Jonathan's irrepressible style (and with the audience's reaction inline).
The talk is an exploration of the differences between static and dynamically typed languages, plus some of the specific language features of Python and IronPython.

My favourite part is where he discusses the cost of compile time checking. Those who advocate the benefits of statically typed languages often discuss what losing compile time checks costs, what they don't talk about so often is what keeping them costs:

"So let’s examine what we’re really talking about losing when we have no compile-time type checks. As we’ve noted, type safety really does catch and eliminate a whole class of errors, namely whenever you perform an operation that expects one data type, and you give it another. However, and importantly, this is not remotely sufficient to have any confidence that a program actually works, just because it compiles. There are many other classes of error that can and do commonly happen.

Jay Fields has a marvellous blog post about this, in which he hypothesises a function performing integer addition. Now, static type checking can confirm that all uses of your function pass it integers, and that the return value is always an integer. Obviously this is not sufficient to assure the function behaves correctly. Nowadays, when we want to be sure about the behaviour of something like this, we write unit tests.

Out of interest, how many people here are using unit tests? [almost every hand goes up] Alright, excellent, of course you do, you’re all professional, and it’s become mandatory, right, because they are so great. So absolutely everybody wants to be using unit tests, no matter if you’re using a static language or a dynamic language. And your unit tests get to be very detailed about the runtime behaviour of your functions, so they don’t simply check that your function is returning an integer, they are testing that 1+1 actually returns 2. Now, 2 is an integer, right? So once these tests are in place, the static type check is now redundant. It is providing no value, and can safely be removed.

Cue sharp intake of breath from everyone in the room currently working on compilers.

Interestingly, when I first started working with Python, I hadn’t used any dynamic language before that, and I was concerned about this myself. I imagined development could be inundated by multiplying bugs which we otherwise would have caught cheaply, at compile time. And this has an element of truth in it - we do find that we get some bugs which normally would have been flagged by the compiler. But it turns out, in practice, these errors are only a very small proportion of all the bugs that any application contains. And also, they are also amongst the most superficial. We passed in function parameters in the wrong order. We supplied a string when we should have used an integer. These are the sort of bugs which are generally trivially easy to locate, identify and fix. They are not the sort of errors that require hours to track down, or make you belatedly realise that you need to redesign the whole project. They are often simple typos, revealed immediately, with a line number, in stack trace that happens the second you run your application. In short, the actual cost of losing type safety is, surprisingly, actually negligible in practice.

People find this hard to accept. It surprised me. So much effort is expended maintaining type safety, it’s such a pervasive feature of almost everything we do in a static language, that it seems inconceivable we could live without it. But interestingly, once we notice how small the actual benefits of type safety are, the other thing you start to notice almost immediately afterwards, is that type safety also comes with a bunch of costs. And these costs are always overlooked, because type safety is so pervasive that it has become invisible, nobody even thinks about it when they have to jump through hoops to maintain it. It’s only when you consider not doing, by using a language that doesn’t enforce it, that you start to realise how huge the costs actually are.

These costs come in two forms, both the direct costs of having to jump through hoops, and also indirect ones, where the restrictions introduced in the name of type safety will fence off ways of doing things that are simply made impossible in a static language."

UPDATE: Comments from the reddit thread that I thought worth posting.
"your unit tests get to be very detailed about the runtime behaviour of your functions... So once these tests are in place, the static type check is now redundant. It is providing no value, and can safely be removed"

The last statement is simply false: If you remove the type checker, you actually have to add more tests. You cannot "safely remove" the type checker just because you have unit tests in a statically typed language.
My response:
Actually your statement is false for another reason - duck typing.

When you test in a dynamic language what you largely test for is that the code performs the correct operations on your objects - and so what type they are is irrelevant so long as they are used in the correct way. This is where the added flexibility of dynamic languages come from.

If your code performs the correct operations then it must behave correctly when passed the correct types (and of course you test that it is called in the correct way - but again not necessarily specifically caring about types).

Programming in dynamic languages is simply a different mindset to programming in statically typed languages - which is why the two camps disagree so much. Caring about type safety is not something that matters a great deal to dynamic language programmers, what matters is the way their objects are used.

NWSGI 1.0 Released

Jeff Hardy announced today the 1.0 release of NWSGI, a Web Server Gateway Interface (WSGI) for IronPython.

"I'm very pleased to announce the release of NWSGI 1.0. NWSGI is an implementation of the WSGI specification (PEP 333) for IronPython. It is implemented as an ASP.NET HttpHandler and is supported on IIS 6 and IIS 7 (and should work on any other ASP.NET-capable web server). NWSGI allows the integration of Python applications with existing ASP.NET facilities such as caching, sessions, and user management."
In the blog entry Jeff notes that NWSGI is a "nearly-complete" implementation of the WSGI specification. On deployment he says:

"NWSGI fully supports xcopy deployment and medium trust environments (with the caveat that parts of the Python standard library are not supported). There is also an installer available that provides a managment UI for IIS 7."

Saturday, December 27, 2008

IronPython and the Spark View Engine

The Spark View Engine is "a view engine for Asp.Net MVC and Castle Project MonoRail frameworks. The idea is to allow the html to dominate the flow and the code to fit seamlessly".

It now supports IronPython:

About Iron Python

IronPython is a dynamic language runtime (DLR) based implementation of Python. Spark scripting is based on assemblies in the 2.0 Release Candidate 1 binary zip. Other good resources are the Python documentation and the Python site itself.

The support for the DLR is very Asp.Net MVC centric. If there's an interest in expanded Castle MonoRail support, please speak up in the discussion group.

Creating a new project

A standard Asp.Net MVC web application is always a great starting place. First, add references to the following assemblies:

  • Spark.dll
  • Spark.Python.dll
  • Spark.Web.Mvc.dll
  • Spark.Web.Mvc.Python.dll

And the following from the IronPython release which are available in the Spark bin\dependencies folder. If you have problems with the these files from Codeplex try the ones in from the Spark distribution. You have the "works on my machine" guarantee.

  • Microsoft.Scripting.dll
  • Microsoft.Scripting.Core.dll
  • Microsoft.Scripting.ExtensionAttribute.dll
  • IronPython.dll
  • IronPython.Modules.dll

Yeah, I know. It's a lot of assemblies. You're going to love the next part though, adding the Spark view engine to an Asp.Net MVC web application has been simplified.

Add the following to your Global Application_Start method:

using Spark.Web.Mvc.Scripting;
...
protected void Application_Start(object sender, EventArgs e)
{
SparkPythonEngineStarter.RegisterViewEngine();
}

This will create a view engine and add it to the engines collection.

The Spark engine starter also has several utility methods for more advanced initialization. You can, for example, provide a settings object from code. You can also use the ISparkServicesContainer to provide specific implementations of different services used by the Spark engine.

OWL BASIC parser and abstract syntax tree

The first programming language I ever used was a version of BASIC on the BBC Microcomputer (over 20 years ago and counting). It did use line numbers, but had procedures and subroutines and allowed you to do structured programming including recursion. Having a programming language built into the machine made it incredibly simple to start hacking - and it even included an assembler so you could embed assembly language in basic programs. A lot of games on the machine started with a shell of basic that would bootstrap the game actually written in assembler.

Robert Smallshire has been working on an implementation of BBC Basic written in IronPython:
"Other personal projects, of both a software and familial nature have taken priority lately over my project to implement a BBC BASIC-a-like compiler for the .NET CLR, now called OWL BASIC in honour of the owl logo of the BBC’s Computer Literacy Project."

This blog entry is mainly focused on the front end parser which uses the Python PLY (Python Lex and Yacc) parser toolkit. This works very well with IronPython and is what we use at Resolver Systems for our spreadsheet formula language. As well as describing the grammar, Robert goes into the details of working with the AST (Abstract Syntax Tree) of parsed BASIC.

"Once the AST has been created by the parser, it can be analysed or manipulated by a visitor. One such visitor, which is an aid to debugging, transcribes each AST node into an XML representation. This is useful since it allows the AST to be conveniently examined using standard XML capable tools (e.g. a web browser) to aid debugging."

Introducing IronPython

Harry Pierson wrote an article on IronPython for the CoDe magazine. Initially it was behind a paywall, but now the whole article is available to read:
"One of the somewhat frustrating aspects of C# is the amount of structure that gets forced on the developer. Some of the structure is related to static typing, such as specifying variable types and casting operators. However, there are also no stand-alone functions in C#, much less just a bunch of code in a simple script. All functions have to be attached to an object, meaning the simplest implementation of “hello, world!” in C# looks like this":

class Program
{
static void Main()
{
System.Console.WriteLine("Hello, World");
}
}

Contrast that with the Python version:

print "Hello, World”

"Obviously, you don’t judge a language completely by its implementation of “hello, world”. But the point is that Python scales well with complexity."

His conclusion:

"Between significant whitespace and dynamic typing, there’s no question Python is a wholly different development experience from C# or VB. I’m a recent convert to Python from C#, so I know exactly how strange it can feel. But once you get past that feeling of unfamiliarity, you start to see just how productive Python can be."

Friday, December 26, 2008

C# Becomes a Dynamic Language...

This post is a bit late - in fact this news was announced several months ago at this year's Microsoft Professional Developer's Conference.

At the PDC the Dynamic Language Runtime was demonstrated - along with the news that it will be part of .NET 4.0. Both Visual Basic 10 and C# 4.0 will have dynamic elements that make use of the Dynamic Language Runtime.

In a blog entry after the conference Jim Hugunin links to Channel 9 videos of his talk on the DLR and Anders Hejlsberg's talk on the way C# is changing.
C# 4 will allow you to use objects dynamically through a new static declaration. A new keyword that allows you to statically declare dynamic objects!

Objects that are declared as dynamic will have operations on them (attribute lookups, method calling, indexing, numerical operations and so on) done through the DLR.

The intarwebz were awash with the news. Here is a selection of the most interesting and informative responses that I found:
You can try this out with CTP (Community Technology Preview) release of Visual Studio 2010 and a version of IronPython 2.0 (pre-IP 2 final) that targets it:
What are the benefits of having dynamic objects (or even static objects that implement the new IDynamic interface)?

Well, you could declare everything as being dynamic, and then C# effectively would be a dynamically typed language with duck typing - except unlike most dynamic languages you still have a lot of type declarations and you have a compile phase with the DLR used to perform operations through reflection.

Substantially more useful is that it makes integrating code in DLR based languages into a .NET application substantially less painful. Although the DLR hosting API is generally very straightforward to work with, passing objects from IronPython or IronRuby back to C# can be a problem. You have to declare ahead of time what type it will be - and if it is a Python or Ruby object that class won't even exist until runtime. You can now declare them as dynamic objects, and the DLR will use the semantics of the language they are defined in when it uses them. Your dynamic objects will still behave like Python or Ruby objects when used from C#.

The DLR can also be used for late-bound COM, something that hasn't really been possible from C# before. It can also be used to create really fluent APIs when working with things like XML, JSON or an HTML object DOM. Dynamic languages have been able to do object traversal with element names as attribute names for many years - and the equivalent in statically typed languages is more verbose and ungainly.

The C# futures documentation gives this example of using the new dynamic keyword:

dynamic d = GetDynamicObject(…);
d.M(7); // calling methods
d.f = d.P; // getting and settings fields and properties
d[“one”] = d[“two”]; // getting and setting through indexers
int i = d + 3; // calling operators
string s = d(5,7); // invoking as a delegate

It also has this to say:

"The type dynamic can be thought of as a special version of the type object, which signals that the object can be used dynamically. It is easy to opt in or out of dynamic behavior: any object can be implicitly converted to dynamic, “suspending belief” until runtime. Conversely, there is an “assignment conversion” from dynamic to any other type, which allows implicit conversion in assignment-like constructs:"

dynamic d = 7; // implicit conversion
int i = d; // assignment conversion

There's lots more in C# 4 - including named and optional parameters - it's shaping up to be a nice language, for a statically typed one...

Tuesday, December 16, 2008

IronPython 2 Final Released

IronPython 2 final (or Release To Web in Microspeak) is finally out. IronPython 2 targets Python 2.5, is built on top of the Dynamic Language Runtime and runs on .NET 2 SP1, Mono 2.2 and Silverlight.
This release of IronPython includes improvements in many feature areas such as better .NET interop support and hosting Python from managed code. There have been many other major improvements as well. The most notable are:
  • An MSI installer for Windows platforms which includes parts of the CPython 2.5 standard library
  • IronPython assemblies targeting Silverlight and tools such as Chiron to improve the Silverlight dynamic development experience
  • The addition of more C-based standard modules such as cmath and _winreg
  • Significant improvements in importing compatibility and features
  • Distribution of IronPython under the Microsoft Public License which has been approved by OSI
  • Performance improvements. On that note, a new Wiki page has been created for IronPython performance reports
  • Over 500 bugs have been closed in 2.0. 453 of these were reported on CodePlex
  • Support for precompilation of Python source files into a single dll
This seems like an opportune time to remind everyone that we fix bugs based on the number of votes they have on CodePlex. As we’re planning on releasing IronPython 2.0.1 fairly soon, please vote for your favorite bugs to help ensure they get fixed in time for the next release.

The IronPython 2 download page also includes some of the IronPython samples that have been converted to work with IronPython 2. One of these is Pyc, the command line compiler tool that creates binary distributions of IronPython applications and libraries.

Along with IronPython 2, there is an official release of the DLR: version 0.9. You can also read the release notes.

The release notes for DLR 0.9 note:

The DLR project provides one-stop shopping for folks who want to:
  • Implement a language on .NET using the DLR
  • Add dynamic features to their existing language like C#’s ‘dynamic’
  • Add scripting to their applications.
  • Create .NET libraries with dynamic objects
This Codeplex project includes the DLR sources as well as sources for IronPython, IronRuby, and samples (such as ToyScript).

We’re shipping some of this in the .NET 4.0 release coming up. Some parts are still open to design changes as we solidify those parts for post .NET 4.0, and we’ll continue to add more docs and samples. We will have coordinated releases or sync points across IronPython and IronRuby sites for major releases so that if you’re not pulling from the DLR project, you can still see which sources or releases are consistent across our projects.

Jim Hugunin did a great talk at PDC 08 on DLR architecture, concepts, and coding with the .NET 4.0 functionality.

If you want to read some documents without downloading sources or bits, you can read the DLR specs.

There is a discussion list (click on the “get email notifications” link). All mail there goes to dlr@microsoft.com which has all the folks working on the DLR and our languages on it.

Wednesday, December 10, 2008

Try Python and IronPython Web IDE Updated for Silverlight 2

I still haven't got around to posting updated versions of my IronPython and Silverlight 2 articles and examples. (However the IronPython in Action early access version does cover the final version of Silverlight 2.) What I have done is put online updated versions of Python in the Browser (an interactive Python interpreter that runs in an HTML textarea) and the IronPython Web IDE (a tool for experimenting with the Silverlight APIs live from IronPython - pre-loaded with examples).

IronPython is the new IValueConverter, IMultiValueConverter

A blog entry on using IronPython to create a DSL (Domain Specific Language) to evaluate expressions in WPF XAML (the XML used to describe user interfaces for Windows Presentation Foundation and Silverlight):
"Applying simple mathematical operations inside WPF DataBindings has always been a non-trivial task. By default the {Binding} or MultiBinding syntax does not allow the use of arbitrary expressions inside the Path."

"There are several cases where you would like to do a little bit of math inside of the {Binding} expressions."

"This requires the use of a converter that would do the actual mapping of values to the bounds of the Canvas."

"Ideally you would want the complete flexibility of a scripting language inside of your Binding expressions. Note however that there is a tendency to over-use / abuse a scripting functionality. That however is for the team to decide what level of sanity needs to be maintained in the script. With judicious usage, a scripting language for evaluating binding expressions is supremely powerful. As of today, IronPython is a great choice for exposing scripting functionality."

"ScriptConverter is a custom converter that I implemented that evaluates python expressions and statements. It hosts an IronPython engine and evaluates scripts specified inside the binding expression. Note that it is just a class that implements both IValueConverter and IMultiValueConverter. It is not a MarkupExtension or a custom Binding class, although one could certainly do both. The decision to implement it as a converter rather than a markup-extension was purely to keep the well-known {Binding} and MultiBinding syntax in your Xaml files."

Saturday, December 06, 2008

IronPython and [Insert MSFT Technology Here] (Starting with WPF)

Back in November (yes, I'm still behind on my posts but catching up), Harry Pierson (IPy PM) announced his decision to write a series of posts on how to use IronPython with a range of different Microsoft technologies:
Making good on his promise he starts with 6 posts on using the WPF (Windows Presentation Foundation) GUI toolkit with IronPython.

In the first part he starts a WPF based photo viewer for his wife's Windows Live photo collection.

"Turns out building this app in IPy was fairly straightforward, with a few pitfalls. I wasted half a day digging thru data binding before realized that data binding against IPy objects works out of the box - but only if you type the case of the property correctly (Title != title)..."

"Over the next several posts, I’m going to show you all the code for this app. It’s pretty small, only about 50 lines of app-specific python code + 50 lines of XAML to describe the window."
In part 2 Harry uses Expression Blend to design the User Interface and then loads the XAML it produces from IronPython:


def LoadXaml(filename):
from System.IO import File
from System.Windows.Markup import XamlReader
with File.OpenRead(filename) as f:
return XamlReader.Load(f)

He hooks up the events to the WPF Window loaded from the XAML and even shows a bit of C# with custom hooks to make it play nicely with IronPython.
Here’s the short version of this post: data binding in WPF to IPy objects just works... mostly. (For the longer version click though to the entry.)
Downloading the RSS feeds used by the WL Spaces Photo Viewer can take several seconds. Harry illustrates how to move functions into the background (not holding up the GUI thread) using a thread pool. To keep things clean (and Pythonic) he uses decorators to execute functions in the background or on the UI thread.
An alternative way of handling the background processing that uses SynchronizationContext instead of the WPF dispatcher.
Another change. The threading code is available for download from Harry's skydrive.
Implementing a REPL (Read-Eval-Print-Loop) so that he can poke around inside his application whilst it is running. This reuses components provided by IronPython to support the interactive interpreter.

Welcome David DiCato to the IronPython Team

Shri Borde (IronPython/IronRuby dev lead) just posted this to the IornPython mailing list:

Please welcome David DiCato to the IronPython team. He has his first shelveset in the Snap queue (queue.__init__ calls clear) already. You should hopefully hear more from him in the mailing list. Here is his intro in his own words.

"Hi everyone, I’m David DiCato, the new Dev on the IronPython team. I grew up in Surf City (i.e. Huntington Beach, CA) and moved just 50 miles north to go to school in Pasadena. At Caltech, I earned my BS in Computer Science, applied to Microsoft after a short break, and the rest is history. Although I have never touched a surf board, I like to dabble in snowboarding, as well as piano, guitar and biking, although I’m good at none of these things. I’m also a big fan of music, incl. classic rock, punk and electronic, and film, incl. Kubrick, Hitchcock and Scorsese."

Welcome to David. He doesn't seem to have a blog yet, but he has been warned that as member of the dynamic languages team he needs one...

Friday, December 05, 2008

Silvershell 0.6 Released

Dan Eloff has announced the release of Silvershell 0.6. (Also known as Python/E - Python Everywhere!).
Silvershell is an interactive Python interpreter (for Python 2.5 as it is based on IronPython 2) with two clients (implemented in pure Python). It runs in the browser with Silverlight 2 or on the desktop with a WPF (Windows Presentation Foundation - which means it won't run on Mono) User Interface.


It is much more polished than my Python in the Browser, with features including:
  • Saving of preferences
  • Autocomplete and call tips
  • The ability to switch processing to a background thread
Here is the announcement that Dan posted to the IronPython mailing list:

"New in this release is the ability to run on the desktop with WPF, execution of code in background threads, and a scratchpad canvas for playing with UI controls."

"There are still some bugs lurking in the intellisense code, and I'll be following soon with a bugfix release. But it works, and you can try it out. I find it more user friendly than the command prompt."

As well as being a fun and potentially useful tool, it is a good example of how web and desktop applications can be maintained with similar codebases through Silverlight and WPF.

Wednesday, December 03, 2008

IronPython + F# + Parallel + Async = A Kittehz Brekfst

Concurrency with threading can be a tricky subject, particularly amongst the Python community.



Nick Hodge has a blog entry on using the .NET Parallel Extensions to write concurrent libraries in F#, and then using them from IronPython:
Whilst thread-safety, dead-locks, queues and other nasties are nasty, Microsoft sees the world of n-cores as a software problem to be solved, not ignored. Both at a low-level and a high-level, well constructed and debugged Parallel libraries are appearing to make the splitting of tasks easier.

IronPython implements the Python language on the DLR and subsequently on the CLR, but this does not automagically provide IronPython with threading and parallelism. Nor could I suggest that IronPython is the silver-bullet for clean parallelism with Python. Various projects such as ParallelPython (including cluster support), Stackless Python and the recent python-multiprocessing package are appearing to move CPython into today’s world of n-cores.

IronPython does have kissing-cousin languages like F#. From F#, and the Microsoft Parallel Extensions Jun08 CTP – a parallel library is a .dll away. Step 1: create a .dll from Luca’s demonstration from PDC2008 specifically the MathLibrary/StockAnalyzer. Combining both the async/parallel versions of the F# code with the single-threaded version was easy.

Tuesday, December 02, 2008

LiveFX using IronPython

Ori Amiga is the group program manager of the Live Framework development platform. He has started a blog, and in his first entry he demonstrates how to use the LiveFX SDK from IronPython.

According to the website:

"The Live Framework is the uniform way for programming Live Services from a variety of platforms, programming languages, applications and devices. Consume and combine Live Services to build applications that span across digital devices and the web."

    1. Download and install the latest IronPython console from [here]
    2. Grab the sample LiveOE.py file from [here]
    3. Edit the LiveOE.py file and change the line
      sdkLibsPath = r"..\LiveFrameworkSDK\Libraries\.Net Library"
      to reflect the path where you’ve installed the LiveFX SDK .NET libraries
    4. Launch the IronPython console from the command line: [ipy.exe -X:TabCompletion]
    5. At the console, you can now type something like:
import LiveOE
livefx = LiveOE.Connect("username@live.com", "password")
for i in livefx.Mesh.MeshObjects.Entries:
print i.Resource.Title


Checking Type Contract from IronPython

Ronnie Maor blogs about testing a C# interface interface that is implemented in IronPython. As Python is generally much more relaxed he needs to ensure that IronPython honours the type contract of the interface it is implementing. He tests this by testing the Python code through the C# interface (which will complain loudly if you use the wrong types) - making the calls via reflection.
"One thing I wanted to test is that my class implements the C# interface correctly in terms of methods' signatures. Otherwise IronPython throws an exception when it tries to map the arguments to the python method, or when it tries to convert the return value. However, my tests are in python, and calls to the object from python don't go through the type checking/conversion parts."

"To overcome this, I call the methods using .NET reflection, which mimics a C# call more accurately and goes through the type checking code. Here's the utility class that helps streamline this process:"

Monday, December 01, 2008

IronPython in Action Update and a Review

IronPython in Action, the book co-written by myself and Christian Muirhead, is still wending its way towards actually being available in the shops. It's currently going through copy editing and technical review. The copy editor is doing a fantastic job of fixing all our grammar and punctuation and generally making the book a better read for those who are bothered by errant commas and semi-colons. Dino Veihland is very kindly acting as our technical reviewer; and is also doing a marvellous job.

Meanwhile, for those who don't want to wait, the full text of the book (pre-copy editing and without the appendices - but still awesome) is available via the Manning Early Access Program. This gets you a PDF version now, and a hardcopy when the book hits the trees. The early access version has just been updated to cover the latest versions of the IronPython 2 hosting API, ASP.NET IronPython integration and Silverlight 2:
Davy Mitchell has been reading the early access version, and has posted a review:
He seems to like it:

"In conclusion, if you are interested in IronPython this book is a must for your bookshelf. 'IronPython In Action' gives a packed tour of IronPython across the key technologies from the desktop, databases, system administration to the web server and client side. Commendably it manages to bring all interested groups along for the ride and you will definitely be inspired to 'Action'. Ho ho. Going back to my initial goals after reading it, I definitely have improved my IronPython, Python and .Net. Result."

Adding References to Assemblies in IronPython

The 'first point' of interoperation between Python code and the .NET framework is the clr module. This allows you to dynamically add references to .NET assemblies in order to be able to import classes from the namespaces they contain.

The clr module has a bewildering array of different functions for adding references to assemblies, and each of them have slightly different semantics and use cases. Dino Veihland (IronPython Developer) recently posted a very useful explanation to the mailing list:

clr.AddReference(str) will first try Assembly.Load and then try Assembly.LoadWithPartialName - this should mean that trying with the strong name won't do anything because LoadWithPartialName will do that for you. This is kind of the one-stop shopping for loading assemblies in the GAC or the app base. If those don't work it will also ultimately search sys.path when the load fails.

clr.AddReference(asm) will just add the assembly that you've already loaded - this is useful if you can load the assembly using some other mechanism (e.g. Assembly.LoadFrom or loading from byte array or whatever)

clr.AddReferenceToFile(str) will search sys.path for the file and load it from there using Assembly.LoadFile. This is good to not have the normal Assembly.Load/LoadWithPartialName mechanisms get in the way.

clr.AddReferenceToFileAndPath(str) will take a fully qualified path, append it to sys.path, and then do Assembly.LoadFile with the path. This is just convenience for quickly adding a fully qualified assembly.

There's also Load* variations which return the assembly object which you can dot through without altering what you can import.

Usually when debugging assembly load failures I use fuslogvw.