Let's Write an LLVM Specializer for Python
dev.stephendiehl.com
Let's Write an LLVM Specializer for Python
1–10 of 45 posts
Re: Let's Write an LLVM Specializer for Python
#2An excellent article! I had wanted to get back into some python recently after seeing the changes in 3.4, I had also wanted to become more familiar with LLVM, and this does both.
Re: Let's Write an LLVM Specializer for Python
#3Very nice article! :)
Storing types via traces could be another step for gathering types. As well as using the more advanced static type checking code that is around for python.
Now I have something to work through on the weekend. Looking forward to part 2!
Re: Let's Write an LLVM Specializer for Python
#4An excellent article! I had wanted to get back into some python recently after seeing the changes in 3.4, I had also wanted to become more familiar with LLVM, and this does both.
there is this discussion (flame war?) about python3 not bringing too many benefits. i haven't made my mind yet. could you elaborate what you saw in 3.4 that was nice?
Re: Let's Write an LLVM Specializer for Python
#5An excellent article! I had wanted to get back into some python recently after seeing the changes in 3.4, I had also wanted to become more familiar with LLVM, and this does both.
there is this discussion (flame war?) about python3 not bringing too many benefits. i haven't made my mind yet. could you elaborate what you saw in 3.4 that was nice?
I'd like to know too. Are there any LLVM specific enhancements that python 3.4 brings to the table?
Re: Let's Write an LLVM Specializer for Python
#6An excellent article! I had wanted to get back into some python recently after seeing the changes in 3.4, I had also wanted to become more familiar with LLVM, and this does both.
there is this discussion (flame war?) about python3 not bringing too many benefits. i haven't made my mind yet. could you elaborate what you saw in 3.4 that was nice?
Simply put: it's a better language. The whole "discussion" is whether it makes sense to migrate since many parts of the ecosystem (many important libraries and frameworks) have not made the transition. And many distros ship Python 2 by default, Python 3 is optional. Python 3 only is not feasible.
To me, the killer feature is better lazy evaluation (generators). In particular, important builtins like map, filter, zip, enumerate, etc are generators, instead of returning lists. This makes it feasible to write things like
(process(line) for line in map(str.upper, open('giantfile.txt')) if line.lstrip()[0] != '#')
Python 3.4 changelog is here, it contains e.g. asynchronous io facilities (asyncio module): https://www.python.org/downloads/release/python-342/
edit: added enumerate() in the example above, for line in open(filename) returns a generator in Python 2.x too.
edit2: enumerate is lazy in python2, I replaced it with map(str.upper)
Re: Let's Write an LLVM Specializer for Python
#7Earlier quoted context omitted.
there is this discussion (flame war?) about python3 not bringing too many benefits. i haven't made my mind yet. could you elaborate what you saw in 3.4 that was nice?
Simply put: it's a better language. The whole "discussion" is whether it makes sense to migrate since many parts of the ecosystem (many important libraries and frameworks) have not made the transition. And many distros ship Python 2 by default, Python 3 is optional. Python 3 only is not feasible. To me, the killer feature is better lazy evaluation (generators). In particular, important builtins like map, filter, zip,…
The example you gave works perfectly in Python 2.7 (would also be a generator, and you're not using map filter or else); but I agree: those should've been generators from day 1, especially zip and enumerate since they make more elegant code but often come with a performance overhead in Python 2.7
Re: Let's Write an LLVM Specializer for Python
#8Earlier quoted context omitted.
there is this discussion (flame war?) about python3 not bringing too many benefits. i haven't made my mind yet. could you elaborate what you saw in 3.4 that was nice?
Simply put: it's a better language. The whole "discussion" is whether it makes sense to migrate since many parts of the ecosystem (many important libraries and frameworks) have not made the transition. And many distros ship Python 2 by default, Python 3 is optional. Python 3 only is not feasible. To me, the killer feature is better lazy evaluation (generators). In particular, important builtins like map, filter, zip,…
(process(line) for line in open('giantfile.txt') if line.lstrip()[0] != '#')
Re: Let's Write an LLVM Specializer for Python
#9An excellent article! I had wanted to get back into some python recently after seeing the changes in 3.4, I had also wanted to become more familiar with LLVM, and this does both.
there is this discussion (flame war?) about python3 not bringing too many benefits. i haven't made my mind yet. could you elaborate what you saw in 3.4 that was nice?
Saner handling of Unicode, for example.
Re: Let's Write an LLVM Specializer for Python
#10Earlier quoted context omitted.
Simply put: it's a better language. The whole "discussion" is whether it makes sense to migrate since many parts of the ecosystem (many important libraries and frameworks) have not made the transition. And many distros ship Python 2 by default, Python 3 is optional. Python 3 only is not feasible. To me, the killer feature is better lazy evaluation (generators). In particular, important builtins like map, filter, zip,…
The example you gave works perfectly in Python 2.7 (would also be a generator, and you're not using map filter or else); but I agree: those should've been generators from day 1, especially zip and enumerate since they make more elegant code but often come with a performance overhead in Python 2.7
Ah, you're absolutely right. for line in open(filename) returns a generator. I added map(str.upper, xxx) there to make it more it make sense.
But the point should be obvious, without generators that would potentially consume a lot of memory.