Live data from Hacker News

Let's Write an LLVM Specializer for Python

dev.stephendiehl.com

21–30 of 45 posts

Re: Let's Write an LLVM Specializer for Python

#21
post #4

An 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?

Without listing any of the modules or improvements that are in the standard library in 3 but backported as PyPI modules to 2 (of which there are many), here are the features that I actually use in Python 3: unicode handling that isn't insane, function annotations, async improvements, exception chaining, enums, single-dispatch generics, better SSL support, generator delegation, better int-bytes conversion support, unittest module improvements.

The key point is that 2.7 is a language frozen in time, while 3.4+ is continuing to develop and improve. And most of the hand-wringing was before the critical mass of third-party modules was ported to 3.x.

https://docs.python.org/3/whatsnew/3.4.html

https://docs.python.org/3/whatsnew/3.3.html

https://docs.python.org/3/whatsnew/3.2.html

https://docs.python.org/3/whatsnew/3.1.html

https://docs.python.org/3/whatsnew/3.0.html

Re: Let's Write an LLVM Specializer for Python

#22
post #6
post #4

Earlier 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,…

You'll get an IndexError exception on that if there are any blank lines in the file.

Changing that to line.lstrip().startswith('#') would be an alternate approach.

Re: Let's Write an LLVM Specializer for Python

#23
post #11

Earlier quoted context omitted.

(process(line) for line in open('giantfile.txt') if line.lstrip()[0] != '#') Is that line really using any new features in Python 3? The lazy evaluation there is in the file object and the generator expression, both of which have long been present in python2.

No, it wasn't. I added map(str.upper, xxx), now it does.

Then again a lazy map is just an import away in P2. It removes pitfalls from Python but the improvement is… very limited (as opposed to e.g. `yield from` which is a big convenience, or for much more specialised uses the ellipsis literal being universal)

Re: Let's Write an LLVM Specializer for Python

#24
post #6

Earlier 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,…

You'll get an IndexError exception on that if there are any blank lines in the file. Changing that to line.lstrip().startswith('#') would be an alternate approach.

You're right but that is irrelevant, it's a somewhat contrived example anyway. It's not like I spent a lot of time trying it out.

Re: Let's Write an LLVM Specializer for Python

#25
post #9
post #4

Earlier 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?

Saner handling of Unicode, for example.

This alone is pretty wonderful. I've only been working in Python a few months and the number of issues I've had to debug in 2.7 that came down to Unicode handling is kind of nuts.

Re: Let's Write an LLVM Specializer for Python

#27

I really appreciate the length and detail in this blog post. It's comprehensive, not just showing off.

Stephen Diehl continues to blow my mind on a regular basis. His latest work in progress "Wrote You a Haskell"[0] is also worth keeping an eye on. I've worked through the first couple of chapters and it's fantastic.

[0] http://dev.stephendiehl.com/fun/

Re: Let's Write an LLVM Specializer for Python

#28
post #4

An 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?

My favorite new feature is PEP-442 [0]. Basically, it's now safe to add a __del__ method to a class without worrying about memory leaks caused by reference cycles.

[0] https://www.python.org/dev/peps/pep-0442/

Re: Let's Write an LLVM Specializer for Python

#29
post #4

An 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?

Add to the list:

- function annotations (allows runtime type checking via third party modules)

- asyncio (not as easy to use as Go's goroutines but still vastly superior to the multiprocessing module)

Re: Let's Write an LLVM Specializer for Python

#30
post #4

Earlier 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?

My favorite new feature is PEP-442 [0]. Basically, it's now safe to add a __del__ method to a class without worrying about memory leaks caused by reference cycles. [0] https://www.python.org/dev/peps/pep-0442/

Most people should not be writing __del__ methods at all, especially if what they are trying to do is deterministic cleanup.
Post reply on HN