Re: [IronPython] Decorators on classes

[Michael Foord]

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 mak

Re: [IronPython] Decorators on classes

[Keith J. Farmer]

"I am only an egg."
 
The basic requirement for IQueryable (and, by extension as it were, the 
interesting variations of LINQ providers) is that the compiler be able to emit 
a series of calls to build expressions.  I only imagine (read:  I haven't 
studied Python's AST offerings) that *for the most part* it should be a fairly 
straightforward mapping of a subset to the new Expressions namespace.  Enough 
that probably a fairly simple visitor could transform from one to the other.
 
Using dotted notation for the query operators themselves is okay.  Creating new 
Expression trees is a PITA without help.



From: [EMAIL PROTECTED] on behalf of Fuzzyman
Sent: Tue 2/5/2008 3:12 AM
To: Discussion of IronPython
Subject: Re: [IronPython] Decorators on classes



Keith J. Farmer wrote:
> Py3k has ASTs, right?
> 
> .. if the ASTs were mapped to System.Linq.Expressions wherever possible, that 
> would be a great start.  Even better if we got complaints if trying to cast 
> an expression that couldn't be cast to the CLR nodes.
>  

Well - Python has had ASTs from the start through the compiler package:

http://docs.python.org/lib/compiler.html

The compiler contains libraries to generate an abstract syntax tree from
Python source code and to generate Python bytecode from the tree.

This is only available in FePy and not straight IronPython.
Additionally, there's a super-secret "_ast" module in Python 2.5. 
Documented in the dev docs for 2.6

  http://docs.python.org/dev/library/_ast.html

The compiler package *is* being replaced in Python 3, but I don't know
the details and a quick googling didn't reveal anything.

Not sure how this helps with LINQ though as I don't believe that Python
3 ASTs will allow you to modify the grammar - so it could only help if
you pass in your queries as strings? (Which is problematic as they need
access to the enclosing namespace of course.)

Michael
http://www.manning.com/foord
> 
>
> From: [EMAIL PROTECTED] on behalf of Michael Foord
> Sent: Mon 2/4/2008 4:09 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Decorators on classes
>
>
>
> Dino Viehland wrote:
>  
>> from future import clr_hacks sounds like the start of an awfully slippery 
>> slope.
>> 
>>
>
> lol :-)
>
> Although I do recall suggesting a while back that it might be impossible
> to avoid incompatible syntax if we are to have full LINQ support in
> IronPython, and that a future import would be one way to go...
>
> Michael
>
>  
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curt 
>> Hagenlocher
>> Sent: Monday, February 04, 2008 2:54 PM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] Decorators on classes
>>
>> On Feb 4, 2008 2:27 PM, Dino Viehland <[EMAIL PROTECTED]> wrote:
>> 
>>
>>> 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
>>>   
>>>  
>> You could theoretically have a "slightly alternate" parsing mode that
>> recognizes a
>> specific class decorator name before the class definition is closed
>> (and therefore
>> before codegen).  In other words, the following definition
>>
>> 
>>
>>> @ClrAttribute(System.SerializableAttribute)
>>> class X(ISomething, object):
>>>   
>>>  
>> treats the decorator differently if it matches one of the special-case
>> names.  The change in parsing could be triggered by something like
>> "from future import clr_hacks".
>>
>>
>> On Feb 4, 2008 2:32 PM, Keith J. Farmer <[EMAIL PROTECTED]> wrote:
>> 
>>
>>> CPythonista outrage over not being able to read something they could
>>> never run is rather silly. :)
>>>   
>>>  
>> You're clearly having trouble envisioning the following Slashdot
>> headline: "Microsoft inflicts 'embrace and extend' on Python".  Silly
>> or not, perceptions are hugely important.
>>
>> --
>> Curt Hagenlocher
>> [EMAIL PROTECTED]
>> ___
>> 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
>>
>> 
>>
>
> ___

Re: [IronPython] Decorators on classes

[Hernan M Foffani]

In our project 98% of attributes are on class definition and properties.
The 2% left are field attributes, [field: NonSerialized()], on user defined
events.


On Feb 5, 2008 1:07 AM, Keith J. Farmer <[EMAIL PROTECTED]> wrote:
> My personal experience says that the most prevalent use of attributes in .NET 
> *is* on methods
> and properties, as part of the original class definition.
>
> Consider:
>
> LINQ to SQL: http://msdn2.microsoft.com/en-us/library/bb386971.aspx
>
> WCF: 
> http://linqinaction.net/blogs/jwooley/archive/2007/05/14/wcf-with-the-linq-to-sql-designer.aspx
>
> XML Serialization: 
> http://www.devhood.com/Tutorials/tutorial_details.aspx?tutorial_id=236
>
>
> 
>
> > It is rather ugly. :-)
>
> Thanks; I thought so myself.
>
> > Would this technique have anything to offer for attributes on methods
> > and properties (etc).
>
> It's hard to see how, but it's been a while since I looked at that
> part of the source.  I'm pretty sure that the CLR class itself needs
> to be emitted entirely by the contents of the one "class" statement --
> and well before the first method is defined.  Which means that none of
> the properties or methods of the class could influence codegen.
>
> Frankly, I don't think that attributes on methods or properties are
> realistic -- at least, not as part of the original class definition.
> What I think you'd be looking at is the ability to define a class
> wrapper that wraps the initially-defined dynamic class with a new
> statically-defined class that allows you to put attributes on methods
> and properties.  Hmm... where have I heard that recently... :)
>
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Decorators on classes

[Fuzzyman]

Keith J. Farmer wrote:
> Py3k has ASTs, right?
>  
> .. if the ASTs were mapped to System.Linq.Expressions wherever possible, that 
> would be a great start.  Even better if we got complaints if trying to cast 
> an expression that couldn't be cast to the CLR nodes.
>   

Well - Python has had ASTs from the start through the compiler package:

http://docs.python.org/lib/compiler.html

The compiler contains libraries to generate an abstract syntax tree from 
Python source code and to generate Python bytecode from the tree.

This is only available in FePy and not straight IronPython. 
Additionally, there's a super-secret "_ast" module in Python 2.5.  
Documented in the dev docs for 2.6

  http://docs.python.org/dev/library/_ast.html

The compiler package *is* being replaced in Python 3, but I don't know 
the details and a quick googling didn't reveal anything.

Not sure how this helps with LINQ though as I don't believe that Python 
3 ASTs will allow you to modify the grammar - so it could only help if 
you pass in your queries as strings? (Which is problematic as they need 
access to the enclosing namespace of course.)

Michael
http://www.manning.com/foord
> 
>
> From: [EMAIL PROTECTED] on behalf of Michael Foord
> Sent: Mon 2/4/2008 4:09 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Decorators on classes
>
>
>
> Dino Viehland wrote:
>   
>> from future import clr_hacks sounds like the start of an awfully slippery 
>> slope.
>>  
>> 
>
> lol :-)
>
> Although I do recall suggesting a while back that it might be impossible
> to avoid incompatible syntax if we are to have full LINQ support in
> IronPython, and that a future import would be one way to go...
>
> Michael
>
>   
>> -Original Message-
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curt 
>> Hagenlocher
>> Sent: Monday, February 04, 2008 2:54 PM
>> To: Discussion of IronPython
>> Subject: Re: [IronPython] Decorators on classes
>>
>> On Feb 4, 2008 2:27 PM, Dino Viehland <[EMAIL PROTECTED]> wrote:
>>  
>> 
>>> 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
>>>
>>>   
>> You could theoretically have a "slightly alternate" parsing mode that
>> recognizes a
>> specific class decorator name before the class definition is closed
>> (and therefore
>> before codegen).  In other words, the following definition
>>
>>  
>> 
>>> @ClrAttribute(System.SerializableAttribute)
>>> class X(ISomething, object):
>>>
>>>   
>> treats the decorator differently if it matches one of the special-case
>> names.  The change in parsing could be triggered by something like
>> "from future import clr_hacks".
>>
>>
>> On Feb 4, 2008 2:32 PM, Keith J. Farmer <[EMAIL PROTECTED]> wrote:
>>  
>> 
>>> CPythonista outrage over not being able to read something they could
>>> never run is rather silly. :)
>>>
>>>   
>> You're clearly having trouble envisioning the following Slashdot
>> headline: "Microsoft inflicts 'embrace and extend' on Python".  Silly
>> or not, perceptions are hugely important.
>>
>> --
>> Curt Hagenlocher
>> [EMAIL PROTECTED]
>> ___
>> 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

Re: [IronPython] Decorators on classes

[Keith J. Farmer]

Py3k has ASTs, right?
 
.. if the ASTs were mapped to System.Linq.Expressions wherever possible, that 
would be a great start.  Even better if we got complaints if trying to cast an 
expression that couldn't be cast to the CLR nodes.



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



Dino Viehland wrote:
> from future import clr_hacks sounds like the start of an awfully slippery 
> slope.
>  

lol :-)

Although I do recall suggesting a while back that it might be impossible
to avoid incompatible syntax if we are to have full LINQ support in
IronPython, and that a future import would be one way to go...

Michael

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curt 
> Hagenlocher
> Sent: Monday, February 04, 2008 2:54 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Decorators on classes
>
> On Feb 4, 2008 2:27 PM, Dino Viehland <[EMAIL PROTECTED]> wrote:
>  
>> 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
>>
>
> You could theoretically have a "slightly alternate" parsing mode that
> recognizes a
> specific class decorator name before the class definition is closed
> (and therefore
> before codegen).  In other words, the following definition
>
>  
>> @ClrAttribute(System.SerializableAttribute)
>> class X(ISomething, object):
>>
>
> treats the decorator differently if it matches one of the special-case
> names.  The change in parsing could be triggered by something like
> "from future import clr_hacks".
>
>
> On Feb 4, 2008 2:32 PM, Keith J. Farmer <[EMAIL PROTECTED]> wrote:
>  
>> CPythonista outrage over not being able to read something they could
>> never run is rather silly. :)
>>
>
> You're clearly having trouble envisioning the following Slashdot
> headline: "Microsoft inflicts 'embrace and extend' on Python".  Silly
> or not, perceptions are hugely important.
>
> --
> Curt Hagenlocher
> [EMAIL PROTECTED]
> ___
> 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

Re: [IronPython] Decorators on classes

[Michael Foord]

Dino Viehland wrote:
> from future import clr_hacks sounds like the start of an awfully slippery 
> slope.
>   

lol :-)

Although I do recall suggesting a while back that it might be impossible 
to avoid incompatible syntax if we are to have full LINQ support in 
IronPython, and that a future import would be one way to go...

Michael

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curt 
> Hagenlocher
> Sent: Monday, February 04, 2008 2:54 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Decorators on classes
>
> On Feb 4, 2008 2:27 PM, Dino Viehland <[EMAIL PROTECTED]> wrote:
>   
>> 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
>> 
>
> You could theoretically have a "slightly alternate" parsing mode that
> recognizes a
> specific class decorator name before the class definition is closed
> (and therefore
> before codegen).  In other words, the following definition
>
>   
>> @ClrAttribute(System.SerializableAttribute)
>> class X(ISomething, object):
>> 
>
> treats the decorator differently if it matches one of the special-case
> names.  The change in parsing could be triggered by something like
> "from future import clr_hacks".
>
>
> On Feb 4, 2008 2:32 PM, Keith J. Farmer <[EMAIL PROTECTED]> wrote:
>   
>> CPythonista outrage over not being able to read something they could
>> never run is rather silly. :)
>> 
>
> You're clearly having trouble envisioning the following Slashdot
> headline: "Microsoft inflicts 'embrace and extend' on Python".  Silly
> or not, perceptions are hugely important.
>
> --
> Curt Hagenlocher
> [EMAIL PROTECTED]
> ___
> 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

Re: [IronPython] Decorators on classes

[Michael Foord]

Curt Hagenlocher wrote:
> On Feb 4, 2008 3:29 PM, Michael Foord <[EMAIL PROTECTED]> wrote:
>   
>> It is rather ugly. :-)
>> 
>
> Thanks; I thought so myself.
>
>   
>> Would this technique have anything to offer for attributes on methods
>> and properties (etc).
>> 
>
> It's hard to see how, but it's been a while since I looked at that
> part of the source.  I'm pretty sure that the CLR class itself needs
> to be emitted entirely by the contents of the one "class" statement --
> and well before the first method is defined.  Which means that none of
> the properties or methods of the class could influence codegen.
>
> Frankly, I don't think that attributes on methods or properties are
> realistic -- at least, not as part of the original class definition.
> What I think you'd be looking at is the ability to define a class
> wrapper that wraps the initially-defined dynamic class with a new
> statically-defined class that allows you to put attributes on methods
> and properties.  Hmm... where have I heard that recently... :)
>   

Getting attributes on classes would be a start - but for example with 
Silverlight you would want to be able to mark methods as 'Scriptable'. 
It sounds like Dino has some ideas on this though.

When I was thinking about auto generating static assemblies from Python 
source it did occur to me that it would be possible to use simple 
markers to enable attributes...

Michael

> --
> Curt Hagenlocher
> [EMAIL PROTECTED]
> ___
> 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

Re: [IronPython] Decorators on classes

[Keith J. Farmer]

My personal experience says that the most prevalent use of attributes in .NET 
*is* on methods and properties, as part of the original class definition.
 
Consider:
 
LINQ to SQL: http://msdn2.microsoft.com/en-us/library/bb386971.aspx
 
WCF: 
http://linqinaction.net/blogs/jwooley/archive/2007/05/14/wcf-with-the-linq-to-sql-designer.aspx
 
 
XML Serialization: 
http://www.devhood.com/Tutorials/tutorial_details.aspx?tutorial_id=236 
 
 



From: [EMAIL PROTECTED] on behalf of Curt Hagenlocher
Sent: Mon 2/4/2008 3:46 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Decorators on classes



On Feb 4, 2008 3:29 PM, Michael Foord <[EMAIL PROTECTED]> wrote:
>
> It is rather ugly. :-)

Thanks; I thought so myself.

> Would this technique have anything to offer for attributes on methods
> and properties (etc).

It's hard to see how, but it's been a while since I looked at that
part of the source.  I'm pretty sure that the CLR class itself needs
to be emitted entirely by the contents of the one "class" statement --
and well before the first method is defined.  Which means that none of
the properties or methods of the class could influence codegen.

Frankly, I don't think that attributes on methods or properties are
realistic -- at least, not as part of the original class definition.
What I think you'd be looking at is the ability to define a class
wrapper that wraps the initially-defined dynamic class with a new
statically-defined class that allows you to put attributes on methods
and properties.  Hmm... where have I heard that recently... :)

--
Curt Hagenlocher
[EMAIL PROTECTED]
___
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

Re: [IronPython] Decorators on classes

[Dino Viehland]

from future import clr_hacks sounds like the start of an awfully slippery slope.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curt Hagenlocher
Sent: Monday, February 04, 2008 2:54 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Decorators on classes

On Feb 4, 2008 2:27 PM, Dino Viehland <[EMAIL PROTECTED]> wrote:
>
> 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

You could theoretically have a "slightly alternate" parsing mode that
recognizes a
specific class decorator name before the class definition is closed
(and therefore
before codegen).  In other words, the following definition

> @ClrAttribute(System.SerializableAttribute)
> class X(ISomething, object):

treats the decorator differently if it matches one of the special-case
names.  The change in parsing could be triggered by something like
"from future import clr_hacks".


On Feb 4, 2008 2:32 PM, Keith J. Farmer <[EMAIL PROTECTED]> wrote:
>
> CPythonista outrage over not being able to read something they could
> never run is rather silly. :)

You're clearly having trouble envisioning the following Slashdot
headline: "Microsoft inflicts 'embrace and extend' on Python".  Silly
or not, perceptions are hugely important.

--
Curt Hagenlocher
[EMAIL PROTECTED]
___
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

Re: [IronPython] Decorators on classes

[Dino Viehland]

This might be something fun to look at during the sprints at PyCon.

-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]

Re: [IronPython] Decorators on classes

[Curt Hagenlocher]

On Feb 4, 2008 3:29 PM, Michael Foord <[EMAIL PROTECTED]> wrote:
>
> It is rather ugly. :-)

Thanks; I thought so myself.

> Would this technique have anything to offer for attributes on methods
> and properties (etc).

It's hard to see how, but it's been a while since I looked at that
part of the source.  I'm pretty sure that the CLR class itself needs
to be emitted entirely by the contents of the one "class" statement --
and well before the first method is defined.  Which means that none of
the properties or methods of the class could influence codegen.

Frankly, I don't think that attributes on methods or properties are
realistic -- at least, not as part of the original class definition.
What I think you'd be looking at is the ability to define a class
wrapper that wraps the initially-defined dynamic class with a new
statically-defined class that allows you to put attributes on methods
and properties.  Hmm... where have I heard that recently... :)

--
Curt Hagenlocher
[EMAIL PROTECTED]
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Decorators on classes

[Keith J. Farmer]

On the contrary, I have no problem whatsoever envisioning any outrageous 
headline on Slashdot, regardless of the actual facts.  I left that crowd many 
years ago.



From: [EMAIL PROTECTED] on behalf of Curt Hagenlocher
Sent: Mon 2/4/2008 2:54 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Decorators on classes



On Feb 4, 2008 2:32 PM, Keith J. Farmer <[EMAIL PROTECTED]> wrote:
>
> CPythonista outrage over not being able to read something they could
> never run is rather silly. :)

You're clearly having trouble envisioning the following Slashdot
headline: "Microsoft inflicts 'embrace and extend' on Python".  Silly
or not, perceptions are hugely important.


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

Re: [IronPython] Decorators on classes

[Michael Foord]

Curt Hagenlocher wrote:
> Here's an implementation idea that may require less work at the 
> expense of less-elegant syntax. 
>  
> class X(object, clr.AttributeBase(System.SerializableAttribute))
> pass
>  
> NewTypeMaker would look for base classes of whatever built-in type is 
> returned by clr.AttributeBase and would use that information to 
> decorate the generated type.
>  

That wouldn't play well with metaclasses, which isn't a showstopper.

It is rather ugly. :-)

Would this technique have anything to offer for attributes on methods 
and properties (etc).

Michael

> --
> Curt Hagenlocher
> [EMAIL PROTECTED] 
> 
>
> ___
> 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

Re: [IronPython] Decorators on classes

[Keith J. Farmer]

We would need this to apply to what would be CLR properties, fields, and 
methods.



From: [EMAIL PROTECTED] on behalf of Curt Hagenlocher
Sent: Mon 2/4/2008 3:17 PM
To: Discussion of IronPython
Subject: Re: [IronPython] Decorators on classes


Here's an implementation idea that may require less work at the expense of 
less-elegant syntax. 
 
class X(object, clr.AttributeBase(System.SerializableAttribute))
pass
 
NewTypeMaker would look for base classes of whatever built-in type is returned 
by clr.AttributeBase and would use that information to decorate the generated 
type.
 
--
Curt Hagenlocher
[EMAIL PROTECTED]
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Decorators on classes

[Keith J. Farmer]

If I can come to terms with Peter Jackson's portrayal of LotR...
 
I said it was silly.  I didn't say the reasons didn't exist.



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



Keith J. Farmer wrote:
> 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. :)
>  
I would see it as more of a concern that IronPython is no longer a
faithful implementation of Python but a hybrid language that is mostly
Python and partly something of Microsoft's invention.

Python has been evolved gradually and gracefully under the hands of
Guido, the core developers and the community. Microsoft has no place
introducing incompatible syntax and wanting the community to still think
of it as Python. I'm sure the IronPython team are aware of this. :-)

Michael
http://www.manning.com/foord


> 
>
> 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.
>

Re: [IronPython] Decorators on classes

[Curt Hagenlocher]

Here's an implementation idea that may require less work at the expense of
less-elegant syntax.

class X(object, clr.AttributeBase(System.SerializableAttribute))
pass

NewTypeMaker would look for base classes of whatever built-in type is
returned by clr.AttributeBase and would use that information to decorate the
generated type.

--
Curt Hagenlocher
[EMAIL PROTECTED]
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Decorators on classes

[Michael Foord]

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 wi

Re: [IronPython] Decorators on classes

[Curt Hagenlocher]

On Feb 4, 2008 2:27 PM, Dino Viehland <[EMAIL PROTECTED]> wrote:
>
> 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

You could theoretically have a "slightly alternate" parsing mode that
recognizes a
specific class decorator name before the class definition is closed
(and therefore
before codegen).  In other words, the following definition

> @ClrAttribute(System.SerializableAttribute)
> class X(ISomething, object):

treats the decorator differently if it matches one of the special-case
names.  The change in parsing could be triggered by something like
"from future import clr_hacks".


On Feb 4, 2008 2:32 PM, Keith J. Farmer <[EMAIL PROTECTED]> wrote:
>
> CPythonista outrage over not being able to read something they could
> never run is rather silly. :)

You're clearly having trouble envisioning the following Slashdot
headline: "Microsoft inflicts 'embrace and extend' on Python".  Silly
or not, perceptions are hugely important.

--
Curt Hagenlocher
[EMAIL PROTECTED]
___
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Re: [IronPython] Decorators on classes

[Michael Foord]

Keith J. Farmer wrote:
> 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. :)
>   
I would see it as more of a concern that IronPython is no longer a 
faithful implementation of Python but a hybrid language that is mostly 
Python and partly something of Microsoft's invention.

Python has been evolved gradually and gracefully under the hands of 
Guido, the core developers and the community. Microsoft has no place 
introducing incompatible syntax and wanting the community to still think 
of it as Python. I'm sure the IronPython team are aware of this. :-)

Michael
http://www.manning.com/foord


> 
>
> 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 havin

Re: [IronPython] Decorators on classes

[Keith J. Farmer]

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 &q

Re: [IronPython] Decorators on classes

[Dino Viehland]

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

Re: [IronPython] Decorators on classes

[Keith J. Farmer]

Python decorators may be sugar, but .NET Attributes are not -- they're metadata 
that there's no way to emit, currently, without using Reflection API arcana, 
and no way to append to a type or member that already exists.



From: [EMAIL PROTECTED] on behalf of Michael Foord
Sent: Mon 2/4/2008 2:02 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.
>>
>> W

Re: [IronPython] Decorators on classes

[Michael Foord]

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

Re: [IronPython] Decorators on classes

[Michael Foord]

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 attr

Re: [IronPython] Decorators on classes

[Dino Viehland]

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.

-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 wo

Re: [IronPython] Decorators on classes

[Keith J. Farmer]

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 mail

Re: [IronPython] Decorators on classes

[Michael Foord]

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

Re: [IronPython] Decorators on classes

[Keith J. Farmer]

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

Re: [IronPython] Decorators on classes

[Curt Hagenlocher]

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

Re: [IronPython] Decorators on classes

[Michael Foord]

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

Re: [IronPython] Decorators on classes

[Curt Hagenlocher]

I, too, wish that Python had class decorators.  However, given that Python
3000 is decidedly and explicitly not backwards-compatible with Python 2.x,
it seems clear that there should eventually be two flavors of IronPython --
2.x-compatible and 3000-compatible.  And I'd be concerned about adding
Py3-specific features to IP2x unless Py2x does likewise.

On the other hand, what harm can there be in "from future import
class_decorators"?

On Feb 4, 2008 10:44 AM, Keith J. Farmer <[EMAIL PROTECTED]> 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

[IronPython] Decorators on classes

[Keith J. Farmer]

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