(All tags.)
Here’s a small problem I’ve seen where several modules share versions of the same “constant” variable. It came up in the context of a Django project with multiple settings files, but it could happen in different contexts.
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.
Here’s an innocent enough looking Python file:
SimpleNamespace
When testing Python code you may need a mock object. That’s okay! But what’s the best way to build a simple mock?
On Monday I released my new book “Boost Your Django DX”. It covers many tools and practices that are useful for developing Django projects.
Python 3.6 reached its end of life on the 23rd December. As its release manager put on the Python forum, it has gracefully “ridden off into the sunset”.
Python’s built-in collection types come in mutable and immutable flavours, but one is conspicuously missing:
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:
If you use Gunicorn, it’s likely you have a configuration file. This is a Python module that contains settings as module-level variables. Here’s an example with some essential settings:
Developer Experience (DX) is a catch-all term for anything that can improve your development workflow. Such improvements can help you write better code, faster, with fewer bugs.