(All tags.)
types moduleWriting type hints gives us some familiarity with the typing module. But Python also includes the similarly-named types module, which can also come in handy. Let’s look at the history of these two modules, some use cases of types, and one way in which it’s not so useful.
Python’s re module lets us search both str and bytes strings with regular expressions (regexes). Our type checker can ensure we call re functions with the correct types, thanks to some parametrized classes.
Here’s a recipe that combines typing.Literal with @overload to define a function that switches its return type based on the value of an argument.
“The Boolean Trap” is a programming anti-pattern where a boolean argument switches behaviour, leading to confusion. In this post we’ll look at the trap in more detail, and several ways to avoid it in Python, with added safety from type hints.
typing.LiteralTo put it tautologically, type hints normally specify the types of variables. But when a variable can only contain a limited set of literal values, we can use typing.Literal for its type. This allows the type checker to make extra inferences, giving our code an increased level of safety.
I released my book “Speed Up Your Django Tests” over a year ago, in May 2020. Since then, we’ve seen two major Django releases, including a whole bunch of test-related changes, some of which I worked on as part of the book.
typing.cast()Python’s dynamism means that, although support continues to expand, type hints will never cover every situation. For edge cases we need to use an “escape hatch” to override the type checker.
time-machine is my library for mocking the current date and time in Python tests. It’s now over a year old, and I just released its version 2.2.0, so I thought it would be nice to summarize recent changes.
Python’s context manager protocol has only two methods, with straightforward types. But when it comes to adding accurate type hints to a context manager, we still need to combine several typing features. Let’s look at how we can do this for the two different ways of making a context manager.
A “magic number” is the anti-pattern of using a number directly rather than storing it in a descriptive variable name. In web code HTTP status codes are often used as magic numbers, perhaps because web developers memorize common codes such as 200 and 404. In Python, we can avoid such magic with descriptive references from the standard library’s http.HTTPStatus enum.
typing.Any in Python’s standard libraryWhen we add type hints, we can find our desire for strictness in tension with Python’s flexibility. In this post we’ll explore three groups of functions in the standard library that I naïvely expected to use narrow types, but due to some edge cases, instead use Any.
TypeGuardI previously covered type narrowing using isinstance(), assert, and Literal. In today’s post we’ll cover TypeGuard, a new special type that allows us to create custom type narrowing functions.
@overloadSometimes the types of several variables are related, such as “if x is type A, y is type B, else y is type C”. Basic type hints cannot describe such relationships, making type checking cumbersome or inaccurate. We can instead use @typing.overload to represent type relationships properly.
It seems inevitable that large projects need some # type: ignore comments, to work around type checking in tricky cases. I’ve found Mypy has a few options to make such ignore comments more precise and manageable.
Mypy does not allow variables to change type. I found this a little bit of a shock at first, but after I adapted, I found my code was more readable.
A couple of recent PEPs have made writing type hints easier:
NoReturn?Sometimes functions never return, for example by always raising an exception. For such functions’ return types, we can “get away” with using None, but it’s best to use the special NoReturn type). This allows Mypy to better find unreachable code (as covered previously). It also shows future readers that the lack of return is intentional.
I recently discovered Mypy has a secondary function as an unreachable code detector. This feature is a great way to highlight places bugs may be hiding, as code paths that can’t possibly run normally show a logical error.
ProtocolDuck typing says “if it quacks like a duck, treat it like a duck.” Type checking seems at odds with duck typing: we restrict variables to named types (classes), allowing only that type or subtypes. This seems like it would stop us from passing in arbitrary objects that can “quack the right way”. But since PEP 0544, we can declare “duckish” types with typing.Protocol.
isinstance(), assert, and LiteralType narrowing is the ability for a type checker to infer that inside some branch, a variable has a more specific (narrower) type than its definition. This allows us to perform type-specific operations without any explicit casting.
In a type hint, if we specify a type (class), then we mark the variable as containing an instance of that type. To specify that a variable instead contains a type, we need to use type[Cls] (or the old syntax typing.Type).
__future__.annotationsPython 3.7 added a new “postponed evaluation” mode for type hints. In this post we’ll cover how it changes the behaviour of type hints, how to activate it, and the outstanding problems.
reveal_type()When working with type hints, it’s often useful to debug the types of variables. Type checkers allow you to do this with reveal_type() and reveal_locals().
Circular imports are always annoying when they arise in Python, and type hints make them more common. Thankfully, there’s a trick to add circular imports for type hints without causing ImportErrors.
Using TypedDict is a great way to type code that passes around dictionaries. The default way to create a TypedDict is with its class-based syntax: