Addition of __clrtype__ to IronPython
One of the important additions to IronPython 2.6 is something that enables several important new ways of integrating with the .NET framework. One the use cases is for .NET attribute support, which has long been missing from IronPython.
The new feature is __clrtype__. This allows you to customize the CLR type used for Python classes. By default a Python class in IronPython is not a true .NET class. This is because Python classes are much more flexible than .NET classes (and can be garbage collected) and are better represented by a .NET object than a .NET type. This unfortunately means that as well as not supporting attributes, Python classes don't play well with any .NET feature that uses reflection over the CLR type to introspect the features of an object. This particularly includes data-binding.
__clrtype__ works by extending the standard Python metaclass mechanism that allows you to customize class creation. To customize the CLR type that forms the underlying type for your class, your metaclass should implement the __clrtype__ method to return a System.Type.
The new __clrtype__ feature is pretty raw, and it likely that layers of functionality can be built on top of it to provide easier access to the things it makes possible.
In the meantime DevHawk (Harry Pierson the IronPython PM) has written a series of blog posts showing how to use the new magic.
The new feature is __clrtype__. This allows you to customize the CLR type used for Python classes. By default a Python class in IronPython is not a true .NET class. This is because Python classes are much more flexible than .NET classes (and can be garbage collected) and are better represented by a .NET object than a .NET type. This unfortunately means that as well as not supporting attributes, Python classes don't play well with any .NET feature that uses reflection over the CLR type to introspect the features of an object. This particularly includes data-binding.
__clrtype__ works by extending the standard Python metaclass mechanism that allows you to customize class creation. To customize the CLR type that forms the underlying type for your class, your metaclass should implement the __clrtype__ method to return a System.Type.
The new __clrtype__ feature is pretty raw, and it likely that layers of functionality can be built on top of it to provide easier access to the things it makes possible.
In the meantime DevHawk (Harry Pierson the IronPython PM) has written a series of blog posts showing how to use the new magic.
In IronPython 2.6, we’re adding the ability to customize the CLR type of Python classes. This means you can add custom attributes, emit properties, whatever you want. For those of you who’ve been dreaming of implementing WCF services or databinding in Silverlight purely in IronPython, then this is the feature for you.
In a nutshell, IronPython 2.6 extends Python’s metaclass feature that lets you to customize the creation of classes. In the metaclass, you can implement an IronPython-specific method __clrtype__ which returns a custom System.Type of your own creation that IronPython will then use as the underlying CLR type of the Python class. Implementing __clrtype__ gives you the chance to implement whatever reflectable metadata you need: constructors, fields, properties, methods, events, custom attributes, nested classes, whatever.
Before we start using __clrtype__ metaclasses, we need to understand a bit about how IronPython maps between CLR types and Python classes. IronPython doesn’t support Reflection based APIs or custom attributes today because IronPython doesn’t emit a custom CLR types for every Python class. Instead, it typically shares a single CLR type across many Python classes. For example, all three of these Python classes share a single underlying CLR type.
Technically, you could emit whatever custom CLR Type you want to in the __clrtype__, but typically you’ll want to emit a class that both implements whatever static CLR metadata you need as well as the dynamic binding infrastructure that IronPython expects. The easiest way to do this is to ask IronPython emit a type that handles all the dynamic typing and then inherit from that type to add the custom CLR metadata you want.
Let’s start simple and hello-worldly by just customizing the name of the generated CLR type that’s associated with the Python class. There’s a fair amount of boilerplate code that is needed even for this simple scenario, and I can build on that as we add features that actually do stuff.
Now that we have the basic __clrtype__ metaclass infrastructure in place, let’s enhance it to add support for CLR fields. To do this, we’re going to need to add two things to our custom CLR type. First, we need to define the fields themselves. Second, we need to make sure that Python code will read and writes to the statically typed fields for the specified names rather than the storing them in the object dictionary as usual. Here’s the updated version of ClrTypeMetaclass.
When I was first experimenting with __clrtype__, I got to the point of making CLR fields work and then immediately tried to do some data binding with Silverlight. Didn’t work. Turns out Silverlight can only data bind against properties – fields aren’t supported. So now let’s add basic property support to ClrTypeMetaclass. Python has a rich mechanism for defining properties, but hooking that up requires DLR binders so for now I’m going to generate properties that are simple wrappers around the associated fields.
I’ve gotten to the point where I can actually demo something interesting with __clrtype__ metaclasses: Silverlight Databinding. This is a trivial sample, data binding a list of Products (aka the sample class I’ve been using all week) to a list box. But according to Jimmy, this is something he gets asked about on a regular basis and there’s a AgDLR bug open for this. The __clrtype__ feature is specific to IronPython but I bet the IronRuby guys could implement something similar if they wanted to.
Comments
Post a Comment