Calvin Spealman set me straight on the true importance of LINQ. Unfortunately the paper doesn't scream the fact that LINQ is designed to be customized based on the data store by fully translating the query code at the CLR level to be specific to the data store. So, for instance, SQL queries can be translated to CLR code for SQL from the lambda expression. So it actually translates the code at the bytecode level to be more efficient.
Now that is more impressive and something Python does not do directly, yet. But with the AST now in, we should end up with an exportable AST that can be directly worked off of to allow something similar to be done if someone decided they wanted to put the time and effort into implementing something like this. But I would not expect to have code-level access to the AST prior to bytecode generation until Python 2.6.
Followers
Subscribe
Posts
Comments
FriendFeed status
Contact Me
Ohloh metrics
Blog Archive
2 comments:
Sorry, that's what I meant with my previous comment. Looks like we managed to convince each other we each knew what the other meant. ;)
Regarding "doing that in Python"--yes! I've been eagerly awaiting the new AST so that I can move Dejavu to it, instead of the ugly bytecode hacks I'm doing now to achieve the same effect. And if we can get Py3k's lambda (or a new expr() beast) to do early binding, it'd be fantastically easier on both sides of the API.
Although we can not, at this time, get the AST for any expressions or blocks prior to compilation, I don't expect or see how or why we would reach this at Python 2.6, either. Firstly, I don't see how python would no to not-compile anything without some special "this is meant to be used just for its AST" syntax. Secondly, I doubt it would be any cheaper to generate the AST without compiling it into bytecode, after factoring in the time it might take to figure out if you need to do so or not. The most likely and efficient way will probably be the most obvious, in this case: pass a function object, built with def or lambda, but expressions by themselves (ie, not lambdas) will be pretty unusable. Anything else would require some kind of mechanism to know that a parameter expects AST, and that would break the python function model. So, barring anything along the lines of function decorators that say "parameter 3 gets the expression's AST" and hooks in the function call mechanism to catch this sort of thing, I don't see the direction of the Python 2.6 comment. Besides, anything along those lines seems like it would pose some serious security risks.
Am I misunderstanding the statement?
Post a Comment