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