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
