Keith J. Farmer wrote: > 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. >
Ok - but unless you want *howls* of outrage from the Python community that had better be done in a way compatible with Python syntax. I really like the way the IronPython team chose to add support for typing (e.g. Array[int]) by overloading existing syntax rather than adding new syntax. For the record I think that reusing Python decorators is *fine* as they are at least analogous concepts even if not identical. I *agree* that being able to access attributes is important to IronPython and really want this to happen... The problem is that attributes can be applied to properties, arguments and return values - which don't sit so well with Python decorators. Nesting class decorators to specify the target could work, and they could be applied at parse/compile time rather than runtime. (With the cost that classes with attributes applied are probably not garbage collectable as they mean creating unique CLR classes.) Michael Foord > ________________________________ > > 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
