(All tags.)
In Python, a mixin class is a class that is not intended to be used directly, but instead “mixed in” to other classes through multiple inheritance. Mixins are not really a language feature but more of a conventional pattern allowed by Python’s multiple inheritance rules. Unfortunately, adding type hints to mixin classes can be tricky because they implicitly require subclasses to fit a certain shape.
Any for unused parameters in testsWhen you create a function to match an interface, it often needs to accept parameters that it doesn’t use. Once you introduce type hints, testing such functions can become a little irksome as Mypy will require all arguments to have the correct types. Your tests can end up creating unused objects only to match the tested function’s signature. Here’s a technique to avoid that work.
Mypy 1.4.0 was released last week (2023-06-20). I’m happy to see it includes three improvements that modernize error messages with newer type hint syntax:
Sometimes code uses boolean checks on variables that can only be true. This is normally a sign of a mistake, either in the type hints or the implementation. Mypy has an optional check that can find such problematic boolean usage with its truthy-bool error code.
The original type hint proposal, PEP 484, initially allowed implicit optional types in function signatures. That is, a parameter with a default value of None would have its type automatically interpreted as optional. For example, this signature:
As type hints have evolved, Python has added simpler, more succinct syntaxes. But you still need to know the older forms, since Mypy uses them when reporting types.
Exhaustiveness checking is a very handy type checker feature. It ensures that all possible types of a variable are handled. If your code changes to add another possible type, you can guarantee that exhaustiveness-checked code paths handle the new case.
Python has no syntax to add type hints to lambdas, but that doesn’t mean you can’t use them in type-checked code. In this post we’ll look at how Mypy can infer the types for lambdas, based on where they’re used.
Hynek Schlawack recently described graduality as Python’s super power: the ability to prototype in the REPL, and gradually add linting, type checking, and other practices to refine your code into maintainable, production-ready software. You can also apply graduality within tools, activating checks one at a time and fixing the resulting errors as you go.
The typing module continues to evolve, with new features in every Python version. This can make it tricky if you’re trying to type code that supports multiple Python versions. To help write such code, Mypy identifies version checks using sys.version_info and reads the appropriate branch.
This post is not about importing typing.Optional, but instead imports that are themselves optional. Libraries often have optional dependencies, and the code should work whether or not the import is there. A common pattern to solve this to catch ImportError and replace the module with None:
The descriptor protocol allow us to completely customize attribute access. Python’s documentation describes the protocol with types involved described with words. Let’s look at how we can write those as type hints.
Earlier this week I shared my Python script template. Here’s an extended version with sub-command support, and an example script.
Python is great for writing scripts for the command line. In this post we’ll look at my script template, an example script, and some alternative versions (without type hints, and in async flavour).
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.
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.
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.
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.