Under the Hood

Normally, when you run a .NET program written in a language such as C# or VB.NET, your code gets compiled to Intermediate Language (IL) code. This code lives inside your .exe or .dll assembly file, and the code contains your class definitions as well as the rest of your code.

In the case of IronPython, the assembly contains the code and classes for IronPython itself, including the IronPython interpreter. When you run the IronPython interpreter, you are running the IL code for IronPython itself. When you run your Python code, IronPython interprets the code. That means the classes you create in your Python code, whether they are native Python classes or CLR classes, are created dynamically at runtime.

In other words, your CLR classes do not live inside the IronPython assembly file. Looking at the source code for IronPython (which ships with the IronPython download), I can see that IronPython makes heavy use of the System.Reflection.Emit namespace of the .NET framework. This namespace includes classes for generating new CLR classes and assemblies dynamically at runtime. It includes a class called TypeBuilder, which is the primary class for creating classes dynamically.

When you declare a new CLR class in IronPython, IronPython calls into the TypeBuilder methods to generate your new CLR class. This happens immediately after the class declaration is interpreted.

However, life in the Python world is a tad bit more complicated than just generating classes immediately after the class declaration. Look at this standard Python example, which uses no CLR features:

class Class1:
    def __init__(self):
        self.Member1 = 'a'
        self.Member2 = 1
        self.Member3 = []

The __init__ function is the constructor. Inside the constructor, I demonstrate how to create members of the class; here, I create three members called Member1, Member2, and Member3 respectively, and I give the first two members initial values. (The third member is an empty list.) If I enter this code at the Python command prompt (using either standard Python or IronPython), and then create an instance of the class, I can list the members of the class, like so:

>>> a = Class1()
>>> dir(a)
['Member1', 'Member2', 'Member3', '__doc__', '__init__', '__module__']
>>>

The dir() function lists names of the members of the object. You can see the three members I created, along with some other built-in members.

So far, this idea of having members is pretty much the same as in any other object-oriented language. However, Python is, in fact, a bit different, in that the members are attached to the objects themselves and can vary within a single class. Take a look at this example:

class Varying:
    def __init__(self, num):
        if (num == 1):
            self.Member1 = 'a'
            self.Member2 = 1
            self.Member3 = []
        else:
            self.Name = 'Fred'
            self.Height = 72

If I paste this code into a Python command prompt, I can then create a couple instances, like so:

>>> a = Varying(1)
>>> b = Varying(2)
>>>
>>> dir(a)
['Member1', 'Member2', 'Member3', '__doc__', '__init__', '__module__']
>>>
>>> dir(b)
['Height', 'Name', '__doc__', '__init__', '__module__']

Notice the members of the two objects as shown in their dir() calls. They differ. Yet, the objects are of the same class. This is where Python is different from other languages. Instead of having a fixed set of members common throughout all instances of a single class, each object has its own set of members. If you want to get technical, however, the members are not members at all. Rather, each object has a single object that is a dictionary, and these members I'm creating are simply placed in the dictionary of each object.

This concept comes into play with IronPython when you create new classes derived from .NET framework classes that have true members. Suppose I create two different classes, both derived from the base class System.Object:

import System
class MyClass1(System.Object):
    def __init__(self):
        self.X = 25
        self.Y = 30

class MyClass2(System.Object):
    def __init__(self):
        self.a = 'abc'
        self.b = 'def'

What's the difference between MyClass1 and MyClass2? They're both derived from System.Object, and they both contain a dictionary of items for the members. And in fact, there is no difference other than the name. The developers of IronPython obviously thought this through very carefully and recognized this point. Thus, only one type is created dynamically through the TypeBuilder class, and that's when the MyClass1 class is created. If this code is pasted into the command prompt, you can verify my assertion:

>>> a = MyClass1()
>>> b = MyClass2()
>>> a.GetType().FullName
'IronPython.NewTypes.System.Object_1'
>>> b.GetType().FullName
'IronPython.NewTypes.System.Object_1'

See, both objects have the same CLR class name. But do a dir() on each object, and you see a different set of members:

>>> dir(a)
['X', 'Y', '__class__', '__doc__', '__init__', '__module__']
>>> dir(b)
['__class__', '__doc__', '__init__', '__module__', 'a', 'b']

So, from a Python perspective, we can think of these two variables a and b as being of different classes. From a CLR perspective, they share the same class. But this only holds for classes created in IronPython that are derived from the same .NET framework class. Thus, if you derive two Python classes from System.Object and a third class from System.Windows.Forms.Form, then the IronPython creates a CLR class for the first two to share, and another separate one for the third to share.

Wrapping Up

In this quick tour of IronPython, I showed you just how you can easily interact with the .NET framework while using the familiar, fun language of Python. The creators of IronPython have gone to great lengths to integrate two worlds that are very different in design.

You can access all the native types and other goodies found in regular Python. And, at the same time, you can easily call into the .NET framework. You can even create your own CLR classes that function seamlessly with the rest of your Python code running under IronPython.

Go ahead and download it, and see for yourself. There's much more than the little I've touched on here. The product includes a tutorial that I recommend you go through to see even more features. Personally, I'm sold.