I was told that numba did similar ast parsing, but maybe that's not true. Regarding the ast, I don't know about reliability, but take a look at get_ast in pyautodiff: https://github.com/LowinData/pyautodiff/blob/7973e26f1c233570ed4bb10d08634ec7378e2152/autodiff/context.py It looks up the __file__ attribute and passes that through compile to get the ast. Of course that won't work when you don't have source code (a .pyc only module, or when else?)
Since I'm looking into this kind of solution for the future of my code, I'm curious if you think that's too unreliable for some reason? From a usability standpoint, I do think that's better than feeding in strings, which: * are not syntax highlighted, and * require porting code from regular numpy expressions to numexpr strings (applying a decorator is so much easier). Best, Neil On Mon, Apr 27, 2015 at 7:14 PM, Nathaniel Smith <[email protected]> wrote: > On Apr 27, 2015 1:44 PM, "Neil Girdhar" <[email protected]> wrote: > > > > I've always wondered why numexpr accepts strings rather than looking a > function's source code, using ast to parse it, and then transforming the > AST. I just looked at another project, pyautodiff, which does that. And I > think numba does that for llvm code generation. Wouldn't it be nicer to > just apply a decorator to a function than to write the function as a Python > string? > > Numba works from byte code, not the ast. There's no way to access the ast > reliably at runtime in python -- it gets thrown away during compilation. > > -n > > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion > >
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
