Recently I posted a short article about how to do simple configuration with IronPython.  I figured that it would be easier with .NET 4.0 thanks to the dynamic support.  And it is.  Using Visual Studio 2010, create a new Console Application.  Add one file called Configuration.py and set the copy output property to Copy Always.  Here’s the Python code for that file:

configuration.Text = "Hello from IronPython"

configuration.Count = 4

And here’s the code for the Program class:

class Program

{

    static void Main(string[] args)

    {

        dynamic configuration = ConfigureFromIronPython();

        for (int i = 0; i < configuration.Count; i++)

        {

            Console.WriteLine(configuration.Text);

        }

        Console.WriteLine("Press any key to exit...");

        Console.ReadKey(true);

    }

    private static dynamic ConfigureFromIronPython()

    {

        dynamic configuration = new ExpandoObject();

        ScriptEngine engine = Python.CreateEngine();

        ScriptScope scope = engine.CreateScope();

        scope.SetVariable("configuration", configuration);

        engine.ExecuteFile("Configuration.py", scope);

        return configuration;

    }

}

For that to work you need add references to IronPython and Microsoft.Scripting (there’s a CTP of IronPython for .NET 4.0 that you can get here.)  You’ll also need a few using statements:

using System.Dynamic;

using IronPython.Hosting;

using Microsoft.Scripting.Hosting;

The two things that make this work are the ExpandoObject and the dynamic keyword.  The ExpandoObject is a dynamic property bag that allows us to set and get members at runtime as needed.  The dynamic keyword means that .NET will resolve the properties at runtime (rather than the traditional behaviour of checking at compile time.)  The result is (I think) more simple and elegant than the configuration code to which I’ve become accustomed.

I’ve just posted an article on how to use IronPython to configure an application – read it here.

Hot on the heels of the release of the National Rail Enquiries Outlook Add-In – which has made it from the Proof of concept to full blown release – we thought we’d make a video about the outcome of the Proof of Concept.  And here it is:

For a look behind the scenes (well, a couple of photos anyway) check out David’s blog.

If you like the sound of IronPython in Action then get your ebook or print copy of IronPython in Action at a 40% discount, courtesy of Manning Publications. Valid only at manning.com/foord – Use code remarkipia40 at checkout.

I first installed IronPython in late 2006  – the combination of .NET and Python being impossible to resist.  My interest and enthusiasm were both raised further by the announcement of the DLR at MIX in 2007.  Since then, I’ve learned about it from blog posts, presentations and occasional bouts of experimentation.  But I always wanted a book about it to learn more and to illuminate the undiscovered corners.  So, I was impatient for the publication of IronPython In Action and bought a copy as soon as it became available.  Having just finished the book, I thought I’d post some thoughts about it.

The first thing I realised when I started to read the book was that the authors, Michael Foord and Christian Moorhead, had to satisfy two discrete audiences: Python programmers interested in the .NET implementation and .NET programmers interested in the DLR and Python.  The result is that there are sections that provide introductions to aspects of both Python and .NET.  I think you’ll want more information on whichever area is new to you, but this is a good starting point.

This is a how-to book, so once the introductions are over, it gets into accomplishing specific tasks.  In doing so, a number of dynamic language attributes like duck typing and first-class functions are introduced.  There’s good coverage of how to use IronPython in a number of .NET technologies such as ASP .NET, WPF, WinForms and Silverlight.

My personal interest was to see how to combine C# and IronPython and this topic is covered including sections on metaprogramming and embedding.  I would have liked to see more on this topic – given the breadth of what is being covered, the consequence has to be that there is a limited amount of space for any given area.  And that for me summarises the book – a very good introduction to what you can achieve with IronPython and the DLR. 

If you’re interested in the DLR and IronPython, this book is worth reading.  It’s a very good introduction  – and will serve as a useful reference when you come to start your next foray into IronPython.  And if you’re not interested in the DLR and IronPython, reading this book may just change your mind.

As Matt announced, the slides from the Architect Insight Conference 2009 are all now online.  The keynote videos are there too.  As Marc notes, there’s something there for most architectural interests – including my session on Dynamic Languages and Architecture (with what could become my trademark use of translucent black.)

I know it’s Friday, but it’s a shame to waste a good title. ..

I thought this article by Martin Fowler about the use of Ruby at Thoughtworks was interesting.  Right at the end there’s an insight into how valuable Ironruby will be to Thoughtworks.  Speaking of Martin Fowler and dynamic languages, it’s also worth checking this post out – it contains some empirical data about how often Thoughtworks developers have to do type checks in Ruby.

I’ve just posted an article about embedding IronPython into your apps as a scripting language. Read it here.

Having posted how to use .NET classes in IronPython, I thought I should repeat the exercise in IronRuby.  I figured I’d use the same assembly I built for the IronPython example.  To start IronRuby (which, again, I’m assuming you have already installed) type ir at a command prompt.  You should see something like this:

First thing is to require the SampleClasses assembly.  Here’s how:

>>>require ‘c:/lib/SampleClasses.dll’

and you should the following output:

=> true

Let’s import the namespace:

>>>include SampleClasses

and the output this time should be:

=> Object

Next, create an instance of the User class:

>>>a = User.new

which should lead to this reponse:

=> SampleClasses.User

Time to set a property:

>>>a.Name = ‘Bob’

and you’ll see that worked from the response:

=> “Bob”

Of course, you can check if you like:

>>>puts a.Name

which will duly report that our user is called Bob:

Bob
=> nil

It really is that easy.   Now you can go and have some fun with IronRuby and .NET assemblies.

It’s really simple to use a .NET class in IronPython.  The first thing to remember is that you’ll need to add a reference (just like you would in .NET).  To do that you use the AddReference method of the clr module.  In the case of an assembly you’ve written, IronPython needs to be able to find it, which means it needs to be in sys.path.  It turns out that you can add the path to your assembly by using the append method of sys.path.  Here’s a simple example.  First, let’s create a simple class called User in C# in a solution called SampleClasses:

namespace SampleClasses

{

    public class User

    {

        public string Name{ get; set;}

        public DateTime DateOfBirth { get; set; }

    }

}

For the sake of simplicity, let’s copy the dll to a folder called lib on the C drive.  OK.  Time to fire up IronPython (which I’m going to assume you’ve already installed.)  Open a command prompt and type “ipy”.  You should see something like the following:

Next, let’s ensure the SampleClasses assembly is available to IronPython:

>>>import sys
>>>sys.path.append(‘C:\\lib’)

Once we’ve done that we can add a reference:

>>>import clr
>>>clr.AddReference(‘SampleClasses’)

Now, we need to import the User name from the SampleClasses namespace:

>>>from SampleClasses import User

We’re all set.  Create an instance of user and set one of the properties:

>>>a.User()
>>>a.Name=’Bob’
>>>a.Name
‘Bob’

That’s all there is to it.  Now you can go and experiment with IronPython and classes you’ve already written in .NET.