I'm fine with something like @clrAttribute[attributeType]("targetIdentifier", 
args).  I'm interested in the feature more than I am in quibbling over specific 
syntax.
 
That said, I question the value of syntax compatibility when the API just 
doesn't exist.  When is CPython ever going to run something that depends on the 
existance of CLR-isms?  Adding the support within existing CPy syntax only buys 
our beloved BDFL the freedom to guide syntax unilaterally.  Not a bad thing, 
mind, and I'm happy to see Guido retain that power, but that's the only 
practical benefit.
 
CPythonista outrage over not being able to read something they could never run 
is rather silly. :)

________________________________

From: [EMAIL PROTECTED] on behalf of Michael Foord
Sent: Mon 2/4/2008 2:09 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Decorators on classes



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


_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Reply via email to