1 HN user recommended this talk1 month2020–2022score 1
Years with an HN recommendation, 2007–2026
HN cites it in Python testing and code quality threads, including his point that 100% coverage proves little.
Raymond Hettinger's PyBay 2018 keynote on preventing, finding and fixing bugs under a time budget. He covers testing practice, type annotation tradeoffs and the limits of coverage metrics.
“This is a good talk by the core developer Raymond Hettinger [1].” (HN, 2021)
This is a good talk by the core developer Raymond Hettinger [1]. He prefers pytest too. I don't do any crazy testing, but I really like property-based testing with Hypothesis, which is also mentioned. This video isn't Python but it's a great intro to property-based testing [2]. 1. [this video] 2. [link]
Yes, they are probably most useful to me for the IDE completions and docs as well. Raymond Hettinger gave at least one talk [1] where he discussed how there are tradeoffs: reasons why you might use them and reasons why you might not. At the end of the day you can pass whatever you want to a function and the only reason to use types if they make your code better—but there are other tools that might be more worth your time in some situations. [1]: [this video]
Hettinger discusses tradeoffs of using type annotations
I had a similar experience after watching a Computerphile video with John Hughes, one of the authors of the original propert-based testing tool, QuickCheck [1]. Running hundreds of thousands of unique tests and finding the simplified cases was mind blowing to watch. I loved the video but my first experience with this method was with Python's Hypotheis [2], I haven't used it a ton but it's great for finding parsing errors. In the words of Python core developer Raymond Hettinger: > It's not quite fuzzing, but it hits it with the kind of test cases that a good QA engineer would typically come up with, and it does it in automated fashion. 1. [link] 2. [link] 3. [this video]
Please see Raymond Hettinger's keynote on efficiently handling bugs[0]. He makes the case that static type checking is a boon for Python except for in specific programs that make extensive use of covariant and/or contravariant types. [0] [this video]
Hettinger's case for static type checking in Python
My examples are just personal anecdotes, you can dismiss them by saying "our team won't make the same mistake". If your goal is 100% coverage then it will turn testing into ritual and only give you the illusion of quality. Instead of testing inputs and edge cases, you will focus on testing lines of code. There's a good illustration of uselessness of 100% coverage in one of Raymond Hettinger talks: [this video] > I use testing as a tool to be sure we ship quality code I suspect we have different definitions of quality, and your might include testing, so I doubt I will be able to convince you.
Video list and Hacker News comment labels from HackerTube (prompted by @karpathy), released under ODC-By 1.0, built on the open-index/hacker-news archive. Hacker News data is provided by Y Combinator; comments remain the work of their authors. Video titles, channel names and thumbnails belong to their creators and are shown via YouTube. HackerTube Watch is an unofficial edition. Data export of 2026-10-31.
Plays via YouTube's privacy-enhanced embed
5 Hacker News comments
From the HN archive; up to 20 kept per video, favoring different commenters. Recommendations first.
Citations, criticism and jokes
Read more