I've had no problems with not grandfathering in older APIs, and am quite happy
to not grandfather in older syntax, either.
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
