Dino Viehland wrote: > This might be something fun to look at during the sprints at PyCon. >
I will definitely be staying for the sprints - either as part of a Resolver sprint or under my own steam... Michael > -----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 > > > _______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
