[IronPython] .NET Attributes

Dino Viehland dinov at exchange.microsoft.com
Mon Mar 27 19:14:45 CEST 2006

This is great feedback....  And yet another way we could consider doing this would be something whacky with metaclasses where we had an "attribute-aware" metaclass or something like that...  But it demonstrates the difficulty in adding support for features like this and the reason we need to tread lightly here.

Do you want to help develop Dynamic languages on CLR?<http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038> (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038)
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Eric Larson
Sent: Monday, March 27, 2006 9:11 AM
To: Discussion of IronPython
Subject: Re: [IronPython] .NET Attributes

On the topic of decorators and integrating with .NET, it seems that in order to keep IronPython as close to CPython, it would be a good idea to consider adding .NET specific pieces as a "library" instead of an addition to the language. That way people could write python code that works in IronPython and CPython equally well without changing radically how the code is written. For example, if I wanted to make a class serializable, it seems logical to inherit from some serializable base class.

from clr.netisms import IPSerializable

class MyClass(IPSerializable):

This may be an obvious solution, but it seems to make more sense to add IronPython specific libraries to help integrate with .NET than to pollute the language. I mention this because one of the great things about Python is the "batteries included" mentality. There are many great libraries that would be excellent to run using IronPython (ZODB for example) that may conflict if the language gets massaged to fit into .NET perfectly. Often times writing to the lowest common denominator can be bad (SQL portability for example), but I believe in the case of Python, whatever can be done to work with the massive amount of libraries will be the most beneficial.

I apologize if this is already addressed. I am thinking about issues such as these from a python programmer's perspective.

Great work!


On 3/27/06, Dino Viehland <dinov at exchange.microsoft.com<mailto:dinov at exchange.microsoft.com>> wrote:
This is a tough problem...  There are two issues here.  But the executive summary here is I'd say the earliest you should *expect* to see this is 1.1, but if (somehow) we end up with some extra time we might have something in the 1.0 timeframe (but don't hold your breath!).

The first issue here is that when your code gets compiled we don't create what are truly .NET classes.  Let's forget about old-style classes for a second (as those are REALLY not .NET classes, and never will be) and instead focus on new-style classes.

When you define a class we'll see if anyone else has inherited from the same set of base-types (including .NET interfaces).  If someone has then we'll use that class instead of creating a new class.  If they haven't we'll derive a new class from your base-class set, overriding all of the virtual methods, and creating some new fields like __dict__ and __class__.  Those fields allow us to both allow you to change the type of your classes at runtime as well as attach new properties to instances.  They also allow us to create a limited number of CLR types (which aren't garbage collected) which means long-running programs creating lots of types don't leak.

In the end there's not really anything good for us to attach the attributes to.  To get that we'd need to move to a more static-compilation model while at the same time retaining the ability to do all the great dynamic stuff with Python.  It's a hard problem and one that we simply haven't solved yet.

The second problem is also just as tough, but it's completely different.  How do you even express an attribute on a class?  There's no Python syntax for this so we'd have to add something new.  It'd be great if we could use decorators here, but they don't apply to classes.  So maybe that's something like __attributes__ = [Serializable, ...] or something along those lines but it's not clear what's the best way to go here...

Do you want to help develop Dynamic languages on CLR? (http://members.microsoft.com/careers/search/details.aspx?JobID=6D4754DE-11F0-45DF-8B78-DC1B43134038 )

-----Original Message-----
From: users-bounces at lists.ironpython.com<mailto:users-bounces at lists.ironpython.com> [mailto:users-bounces at lists.ironpython.com <mailto:users-bounces at lists.ironpython.com> ] On Behalf Of Andrzej Krzywda
Sent: Monday, March 27, 2006 4:55 AM
To: users at lists.ironpython.com<mailto:users at lists.ironpython.com>
Subject: [IronPython] .NET Attributes


When there will be support for .NET Attributes in IronPython?
Is there any way currently to mark my class as Serializable?

users mailing list
users at lists.ironpython.com <mailto:users at lists.ironpython.com>
users mailing list
users at lists.ironpython.com<mailto:users at lists.ironpython.com>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20060327/a1d8241a/attachment.html>

More information about the Ironpython-users mailing list