Django and other frameworks often allow you to configure classes, functions, or modules to import using strings. To do the same in your own code, use pkgutil.resolve_name() from the standard library (added in Python 3.9):
Sometimes, you want to test a function that uses an inner import and mock that imported object. For example, say you wanted to mock dig() in this example:
Copy-paste-tweaking library code feels like a dirty but inevitable programming practice. Often driven by deadlines or other constraints, it seems all projects end up with something copy-pasted in and tweaked for one specific use case.
Many terminals and text editors support what I’ll call “line number paths” of the form <filename>:<lineno>. Opening that path, whether by clicking or passing to a CLI, opens the given file at that line.
Earlier this week, I made another podcast appearance on The Python Show, episode 22: Git and Django with Adam Johnson. As fellow authors, Mike and I talked a lot about the writing process, on topics like:
I had the pleasure of returning to The Real Python podcast in last week’s episode 179, Improving Your Git Developer Experience in Python. It was great to catch up with host Christopher Bailey and chat about:
Most projects I work on use Python, good ol’ Pip, and pip-tools. Below is a pattern I’ve used to speed up the GitHub Actions workflow runs on several such projects. On larger projects with many dependencies, it can save tens of seconds per run.
The Python standard library’s logging module is a go-to for adding observability to applications. Many tools also integrated with it or enhance its capabilities, such as structlog and Sentry.
When trying to improve a slow function or module, it’s always a good idea to profile it. Here’s a snippet for quickly profiling a section of code with Python’s cProfile module, in two flavours. It’s adapted from the cProfile documentation’s Profile example. I have used versions of this snippet over the years to narrow in on performance issues.
When 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:
Here’s an application of “test smarter, not harder”, as per Luke Plant’s post. I came up with this recently whilst working on my client Silvr’s project, and I’m pretty proud of it. It should apply to any project using Django’s admin.
Sometimes you want to download a whole website so you have a local copy that you can browse offline. When programming, this is often useful for documentation that sites that do not provide downloadable versions, and are not available in offline tools like DevDocs.
Your Django project’s startup time impacts how smooth it is to work with. Django has to restart your project every time you run a management command and when runserver reloads. This involves importing all your apps, and thus all the modules that they import.
Python 3.11 only made one change to unittest, but it’s a good one: context manager methods. These methods can simplify setup and teardown logic in many cases, such as dynamic use of unittest.mock.
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 describedgraduality 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.
Django’s transaction.on_commit() allows you to run a function after the current database transaction is committed. This is useful to ensure that actions with external services, like sending emails, don’t run until the relevant data is definitely saved.