This might be something fun to look at during the sprints at PyCon. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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@lists.ironpython.com >>> > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> > >>> > >>> >>> _______________________________________________ >>> Users mailing list >>> Users@lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users@lists.ironpython.com >>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >>> >>> >>> >>> >> _______________________________________________ >> Users mailing list >> Users@lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> _______________________________________________ >> Users mailing list >> Users@lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> _______________________________________________ >> Users mailing list >> Users@lists.ironpython.com >> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com >> >> >> > > _______________________________________________ > Users mailing list > Users@lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > _______________________________________________ > Users mailing list > Users@lists.ironpython.com > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com > > _______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com _______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
