Could this be used to ahead-of-time compile Python code ? I'm more interested in getting to a native executable or library.
Let's Write an LLVM Specializer for Python
41–45 of 45 posts
Re: Let's Write an LLVM Specializer for Python
#42I did something similar in Ruby but using GCC as a "JIT" compiler for image processing (software [1], thesis [2]). I can really recommend JIT compilation for doing array processing. [1] http://www.wedesoft.de/hornetseye-api/ [2] http://www.wedesoft.de/downloads/thesis_wedekind.pdf EDIT: In my approach I didn't go through the Ruby AST though. Rather I used the approach of injecting "GCCVariables" which emit C code ins…
You should submit your thesis to the Ruby Bibliography http://rubybib.org
Ok, will do. Cheers :)
Re: Let's Write an LLVM Specializer for Python
#43I love Python but when I use a statically typed language like C, Rust, Go, etc I really feel that it is missing from Python.
I'd love to see a new language exactly like Python but compiled and statically typed. Something similar to Cython, but rather than generating a bunch of C code it would target LLVM. Additionally it would be able to generate pure Python code simply by removing any typing syntax.
Re: Let's Write an LLVM Specializer for Python
#44Earlier quoted context omitted.
(process(line.upper()) for line in open('giantfile.txt') if line.lstrip()[0] != '#')
That's besides the point. It's trivial to write that as a for loop or in a million different ways to avoid the issue. It's a contrived example written to demonstrate a difference. Here's another one you can't change that easily: tests_pass = all(process(input) == output for (input, output) in zip(open('inputs.txt'), open('outputs.txt'))
You felt the need to correct yourself earlier, so I think your "besides the point" should be directed to yourself. I was pointing out that your correction wasn't persuasive.
Re: Let's Write an LLVM Specializer for Python
#45Earlier quoted context omitted.
That's besides the point. It's trivial to write that as a for loop or in a million different ways to avoid the issue. It's a contrived example written to demonstrate a difference. Here's another one you can't change that easily: tests_pass = all(process(input) == output for (input, output) in zip(open('inputs.txt'), open('outputs.txt'))
You can change that easily, with izip from itertools. The fact that a bunch of builtins and the values/items methods of dictionaries have become iterators is not very siginificant IMHO. Python 2 code could already be written to use iterators or generator expressions, so in the parts where it was crucial it was already done. In this regard Python 3 has not added new functionality but only changed defaults. The unicode…
In this case (checking that process(input) == output), itertools.izip_longest is probably that right solution, unless there's an out-of-band way to know that inputs.txt is the same length as outputs.txt.