Skip to content
Hallway
0:00 / 0:00

#pytest#hypothesis#typeannotations

Keynote - Preventing, Finding, and Fixing Bugs On a Time Budget | Raymond Hettinger @ PyBay2018

SF Python

19K subscribers • 5 videos on Hallway

YouTube
  • Recommended by 1 person: 1 on Hacker News.
  • Presented by Raymond Hettinger, Python core developer
  • An opinion. It argues one side of a question engineers disagree on.

Intermediate. Assumes working knowledge.

27K views8 years ago1 recommendation

Tools and practiceProgramming languagesTestingDebuggingPython

Raymond Hettinger discusses pragmatic testing strategies in Python, including the tradeoffs of type annotations, property-based testing, and the limits of code coverage.

This talk was presented at PyBay2018 - the Bay Area Regional Python conference. See pybay.com for more details about PyBay and click SHOW MORE for more information about this talk. Speaker Bio Raymond is the leader of an international Python training and consulting company and a celebrated speaker in the Python community worldwide. He has been a Python core developer for 16 years, contributing extensively to modules like bisect, collections, decimal, functools, itertools, math, random, with types like namedtuple, sets, dictionaries, etc. He is also known for his contributions to the Python Cookbook and for teaching Python via Twitter. He has also a recipient of Python Software Foundation's Distinguished Service Award. This and other PyBay2018 videos are brought to you by our Gold Sponsor Cisco!

Why it's here

1 person recommends this

What people say. Recommended as a pragmatic guide to Python testing that highlights the tradeoffs of static typing and the illusion of 100% code coverage.

Rendelloon Hacker News • Recommends

On “My Python testing style guide (2017)”

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. link to this video 2. link
View on Hacker News

memcoon Hacker News • Mentions

On “Python at Scale: Strict Modules”

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: link to this video
View on Hacker News

Rendelloon Hacker News • Mentions

On “In praise of property-based testing (2019)”

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. link to this video
View on Hacker News

TrickardRixxon Hacker News • Mentions

On “Boring Python: Code Quality”

Please see Raymond Hettinger's keynote on efficiently handling bugs0. 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 link to this video
View on Hacker News

hbrnon Hacker News • Mentions

On “Boring Python: Code Quality”

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: link to 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.
View on Hacker News