[IronPython] Decorators on classes

Dino Viehland dinov at exchange.microsoft.com
Tue Feb 5 00:54:49 CET 2008 

This might be something fun to look at during the sprints at PyCon.

-----Original Message-----
From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Monday, February 04, 2008 2:55 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Decorators on classes

Hello Dino,

That sounds *great*, and is something really needed by IronPython. How
long do you think it will take you to implement? <0.5 wink>

Michael
http://www.manning.com/foord

Dino Viehland wrote:
> Ok, maybe it's a little optimistic or maybe it needs a couple of hooks exposed, but it's not too crazy.
>
> As other people have pointed out decorators are a runtime concept and I don't think we get to change that.  So consider a class decorator such as:
>
> def ClrAttribute(attr):
>         def attrFunc(class):
>                 # do something smart here with attr
>         return attrFunc
>
> @ClrAttribute(System.SerializableAttribute)
> class X(ISomething, object):
>         @ClrAttribute(SomeOtherAttribte)
>         def DoSomething(self):
>                 return 42
>
>
> As Curt mentioned we do a bunch of caching and such with NewTypeMaker and maybe spit out a new type.  That's all going to happen before the decorator gets to run - but we'll only create a new type once so there isn't too much overhead here :).
>
> >From there you could copy that type w/ Reflection.Emit but add the attribute(s) on it, and then create a new instance of it passing in the PythonType object to its constructor (that's how Python types work - the instance holds onto a copy of the PythonType, the one problem here being that the UnderlyingSystemType of the PythonType would now be wrong, so that might need a hook).  This could also include applying the attributes to methods and potentially manifesting concretely typed methods.   This same sort of approach might even work w/ a meta-class.
>
> Plugging into NewTypeMaker would simplify this but I don't think makes it impossible.
>
> There's also other potential problems with systems based up types and attributes: Sometimes they want a type that lives in an assembly and sometimes they want to create instances of types (and they don't know to pass in a PythonType object to the constructor).
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
> Sent: Monday, February 04, 2008 2:03 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Decorators on classes
>
> Dino Viehland wrote:
>
>> FYI IP 2.0 is tracking 2.5 and we have the big pieces in place plus many small pieces (although there's more to go).  In 1.1 we had -X:Python25 which enabled selective 2.5 features and we could conceptually do the same sort of thing for 2.0 so that it includes one or two 2.6 features such as class decorators.
>>
>> >From there the decorators to support attributes could even be written in Python.
>>
>>
>>
>
> Is that right - could attributes be added to an IronPython class (or
> instances) at runtime using reflection? Earlier parts of this
> conversation implied that this wasn't the case...
>
> Decorators are only syntactic sugar, so the lack of class decorators
> isn't an impediment...
>
> Michael
>
>
>
>> -----Original Message-----
>> From: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] On Behalf Of Keith J. Farmer
>> Sent: Monday, February 04, 2008 1:40 PM
>> To: Discussion of IronPython; Discussion of IronPython
>> Subject: Re: [IronPython] Decorators on classes
>>
>> Grandfathering: Giving more consideration to retaining compatibility than it deserves. :)
>>
>> Obviously, IronPython should prioritize compatibility with Py2.4, but for obvious reasons I limit that to seeing IP as a consumer of CPy, not the other way around.  On the other hand, IP must also be able to consume .NET, and .NET is increasingly making use of things the IP cannot yet express.  (I thought of another framework that attributes are used on -- WCF.  There are also XML serialization attributes.)
>>
>> To that end, I think it would be worthwhile, for the purpose of .NET attributes, to have decorators or their analogues available to IronPython in the current stage of development.  That is, I think it should be that IronPython = CPy 2.4 + .NET Attributes + other .NET-isms expressed in a Pythonic way.
>>
>> ________________________________
>>
>> From: users-bounces at lists.ironpython.com on behalf of Michael Foord
>> Sent: Mon 2/4/2008 11:53 AM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] Decorators on classes
>>
>>
>>
>> Keith J. Farmer wrote:
>>
>>
>>> I've had no problems with not grandfathering in older APIs, and am quite happy to not grandfather in older syntax, either.
>>>
>>>
>>>
>> What do you mean by 'grandfathering' in this context?
>>
>> Michael
>>
>>
>>
>>> I agree that IronPython would have to be able to distinguish between CLR attributes and Python decorators, inasmuch as CLR attributes are a static part of the class/member definition.  But I don't think it's an insurmountable problem, and solving it in the DLR, actually, would be very useful.
>>>
>>> I wouldn't expect that class authors would want to change the set of .NET attributes frequently if at all -- it doesn't match how they've been designed and how they've evolved, so creating the attributed base class once (and then having pythonic decorators coming in and out at will) seems like a reasonable approach to me.
>>>
>>> ________________________________
>>>
>>> From: users-bounces at lists.ironpython.com on behalf of Curt Hagenlocher
>>> Sent: Mon 2/4/2008 11:13 AM
>>> To: Discussion of IronPython
>>> Subject: Re: [IronPython] Decorators on classes
>>>
>>>
>>> Oh! I didn't realize that about 2.6.
>>>
>>> There is indeed a big difference between a Python runtime decorator and a .NET compile time attribute; in fact, the similarities are superficial at best.
>>>
>>> .NET attributes are totally static, so there's no way to modify a .NET class definition to add them.  The IronPython engine would have to recognize particular class-level Pythonic annotations and use that information to emit a new CLR class to represent the Python class.  It already emits CLR classes as needed to represent Python classes.  By "as needed", I mean that a specific CLR base class plus a specific set of CLR interfaces will uniquely determine a class to be emitted by IronPython.  This class is cached so that -- once generated -- any new Python class definition that matches this set of (CLR base class plus interfaces) will reuse the same CLR class definition.
>>>
>>> What you'd have to change is to put the class-level attributes onto the generated CLR class, then change caching so that the key is (CLR base class plus interfaces plus attributes).  It's definitely doable, but raises intriguing questions about "purity".  And you'd also need to consider the impact on the larger DLR.
>>>
>>> Method-level attributes are an entirely different matter.
>>>
>>> On Feb 4, 2008 10:58 AM, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
>>>
>>>
>>>       Class decorators will be in Python 2.6 - but there is a big difference
>>>       between a Python runtime decorator and .NET compile time attributes. Is
>>>       it possible to attach attributes at runtime using the reflection API?
>>>
>>>       Michael
>>>       http://www.manning.com/foord
>>>
>>>
>>>       Keith J. Farmer wrote:
>>>       > Can I resurrect this forgotten soul?  http://www.codeplex.com/WorkItem/View.aspx?ProjectName=IronPython&WorkItemId=13583
>>>       >
>>>       > Having just finished working on LINQ to SQL, I'm convinced that future LINQ providers will be making heavy use of .NET attributes not just on properties, but on classes themselves.  Being able to express these attributes in IronPython is a tremendous bonus.  That there be one and only one way to express these is paramount.
>>>       >
>>>       > _______________________________________________
>>>       > Users mailing list
>>>       > Users at lists.ironpython.com
>>>       > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>       >
>>>       >
>>>
>>>       _______________________________________________
>>>       Users mailing list
>>>       Users at lists.ironpython.com
>>>       http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.ironpython.com
>>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>>
>>>
>>>
>>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>>
>>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>

_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

More information about the Ironpython-users mailing list