Armin Ronacher - A Python for Future Generations
EuroPython Conference4 HN recommenders · recommended in 3 months, 2017-2020
6K views · 9 years ago · talk · evergreen
Armin Ronacher's EuroPython 2017 keynote examining how the CPython interpreter's leaky abstractions affect language design and how Python could evolve, drawing on JavaScript and Rust experience.
Recommended for explaining why Python is hard to optimize and the limits of making it fast.
49:55How Python was Shaped by leaky Internals, Armin Ronacher, Flask framework
Видео с мероприятий {speach!
20K views • 10 years ago
46:10Understanding the Python GIL
David Beazley
127K views • 14 years ago
59:11How to Speed up a Python Program 114,000 times.
InfoQ
171K views • 13 years ago
40:34Charlie Marsh: uv: An Extremely Fast Python Package Manager
Jane Street
107K views • 2 years ago
56:55Q&A with Guido van Rossum, Inventor of Python
Microsoft Reactor
28K views • 5 years ago
1:13:53Raymond Hettinger, Keynote on Concurrency, PyBay 2017
SF Python
161K views • 9 years ago
3:15:51Guido van Rossum: Python and the Future of Programming | Lex Fridman Podcast #341
Lex Fridman
1.8M views • 3 years ago
47:34RailsConf 2011: Aaron Patterson, "Double Dream Hands: So Intense!"
O'Reilly
26K views • 15 years ago
1:01:45A Talk Near the Future of Python (a.k.a., Dave live-codes a WebAssembly Interpreter)
David Beazley
26K views • 7 years ago
1:00:40Dmitry Vyukov — Go scheduler: Implementing language with lightweight concurrency
Hydra
47K views • 7 years ago
44:43Ron Pressler - Pull Push: Please stop polluting our imperative languages with pure concepts-Curry On
Curry On!
25K views • 11 years ago
12:31OSCON 2010: Rob Pike, "Public Static Void"
O'Reilly
119K views • 16 years ago
32:07Larry Hastings - Removing Python's GIL: The Gilectomy - PyCon 2016
PyCon 2016
49K views • 10 years ago
1:24:39Mojo Lang - Tomorrow's High Performance Python? (with Chris Lattner)
Developer Voices
64K views • 2 years ago
45:08Raymond Hettinger - Dataclasses: The code generator to end all code generators - PyCon 2018
PyCon 2018
130K views • 8 years ago
49:54The Clean Architecture in Python
Next Day Video
114K views • 12 years ago
1:00:58CppCon 2017: Chandler Carruth “Going Nowhere Faster”
CppCon
113K views • 9 years ago
34:55"Outperforming Imperative with Pure Functional Languages" by Richard Feldman
Strange Loop Conference
98K views • 5 years ago
1:21:39Making R run Fast - Jan Vitek
John O'Neill
860 views • 10 years ago
1:14:52Effective Programs - 10 Years of Clojure - Rich Hickey
ClojureTV
176K views • 9 years ago
4 comments from Hacker News
As the OP states: > mutable interpreter frames, global interpreter locks, shared global state, type slots On top of this, Python is extremely dynamic and nothing can be assured without running through the code. So this leads to needing JITs to improve performance which then give a slow start up time and increased complexity. Even with JIT, Python is just not fast thanks to the above issues and it's overall dynamism. It can be optimised and for sure there's some impressive attempts at doing so. However I don't think pure Python will ever be considered "fast" as these things necessarily get in the way. I highly recommend the two videos posted here that go into more detail as to why there are limits to how far optimisation can go: link ▶ this video
I found the following talks by Armin Romacher very informative on these topics (C API, why python is more difficult to speed up than JS). link ▶ this video I wish these were the things Python 3 addressed, rather than Unicode. I guess it's much more obvious in hindsight than back when Python 3 was designed.
Python's success is richly deserved. The fact that it has been a long time coming (Python is almost 30 years old!) is an indication of the amount of sheer effort involved, and should give heart for all those working on building up the next generation of languages. Since this forum is likely to have some folks looking towards the future, I found interesting a couple of talks by Python veteran Armin Ronacher [1, 2]. Watching that presentation makes me wonder whether I should think of this in the context of "Worse is better". That said, Python's runtime introspection is such a killer feature that it's difficult to explain how empowering it feels for someone who is relatively new to programming. [1]: How Python was Shaped by leaky Internals -- link [2]: A Python for Future Generations -- ▶ this video
As far as I understand, one important difference is that JavaScript doesn't have __getattr__ or __setattr__ (or at least earlier versions didn't). You might not use those hooks a lot in your application code, but it seems that web frameworks and the like do a lot of reflection, which makes the code difficult/impossible to optimize (even at runtime with a JIT). Python also has __add__ (operator overloading) and JavaScript doesn't. This is a good talk about how subtle or crufty the semantics of something like "a+b" is in Python: ▶ this video The PyPy developers had to copy a lot of the implementation details of CPython, which doesn't always result in the fastest code.