[IronPython] Decorators on classes

Keith J. Farmer kfarmer at thuban.org
Tue Feb 5 10:55:58 PST 2008


"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: users-bounces at lists.ironpython.com 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: users-bounces at lists.ironpython.com 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: users-bounces at lists.ironpython.com [mailto:users-bounces at lists.ironpython.com] 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 <dinov at exchange.microsoft.com> 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 <kfarmer at thuban.org> 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
>> curt at hagenlocher.org
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>> _______________________________________________
>> Users mailing list
>> Users at lists.ironpython.com
>> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>>
>> 
>>    
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>  

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




More information about the Users mailing list