A Guide to Python Lambda Functions
In Python, Lambda functions are rare compared to “normal” functions, and occasionally misunderstood or overused.
In Python, Lambda functions are rare compared to “normal” functions, and occasionally misunderstood or overused.
Last week I covered Django’s database instrumentation, and making a wrapper that’s always installed. Here’s a different use case that I encountered last year on a project.
Here’s a small warning I’ve come across a couple of times, and how to fix it with a niche pytest feature.
If you’ve read the Django documentation for Model.Meta.index_together recently, you may have noticed this note:
Since version 2.0, Django has provided a hook for installing database instrumentation wrapper functions. These functions are like middleware for database queries, allowing you to inspect and rewrite SQL before it is sent to the database. There are many use cases, for example:
Django’s test command takes the --parallel flag to activate parallel testing. Unfortunately, this has never worked on Windows, and with Python 3.8 it has stopped working on macOS.
Here’s a conversation I had earlier with the late Ernest Hemingway:
Your Django project may use some packages that add instrumentation, for example:
Since I launched my book Speed Up Your Django Tests I’ve had a number of questions about possible discounts. I want to make my book affordable for all and understand that $49 is a high price tag for some. The Django community is global and I want to share knowledge with Djangonauts everywhere.
A Python decorator wraps a target function with another wrapper function. This wrapper function can add any behavior you might want. For example, it can track execution times, redefine how the wrapped function runs, or modify return values.
Imagine we are installing the third party package django-cors-headers, which I maintain. Step one in its installation process is to install the package, so we run the command:
The /.well-known/ URL path prefix is a reserved name space for serving particular static files used by other systems that might interact with your site. It was established by RFC 5785 and updated in RFC 8615. The IANA maintains a list of possible files in the Well Known URIs registry, but others are in wide use without official registration (yet?).
By default, Python buffers output to standard output (stdout) and standard error (stderr). This means that output from your code might not show up immediately, making debugging harder.
SyntaxWarning: list indices must be integers or slicesTake this code, which we want to return a list of two breakfast orders:
SyntaxWarning: assertion is always trueTake this code:
SyntaxWarning: '<type>' object is not subscriptableTake this code:
SyntaxWarning: '<type>' object is not callableTake this code, which we want to return a list of shopping items with desired quantities:
Django’s test client is really useful for writing integration tests for your project. It’s great because it has a simple API for testing your application similarly to how a web browser would interact with it. Unfortunately it can be slow, because each call creates a request, passes it through all your middleware, view, maybe a template, then the response comes back through the same layers.
This is a test anti-pattern I’ve seen creep in on many Django test suites. I know of several large projects where it became a major undertaking to undo it. The good news is it’s easy to avoid adding it when you first write your tests. 🙂
I encountered this problem recently for a Django ticket for speeding up part of Django’s test runner. We have a list of tables to truncate. How can we figure out which are already empty, so we can skip issuing a somewhat costly TRUNCATE TABLE on them? You might think the database could skip TRUNCATE TABLE on empty tables, but it normally does work beyond removing the rows such as resetting auto-increment counters. In MySQL, TRUNCATE TABLE is even equivalent to DROP TABLE and CREATE TABLE, which requires removing and creating the table file on disk.
Whilst writing Speed Up Your Django Tests, I wanted to add a section about mocking the current time. I knew of two libraries for such mocking, but I found it hard to pick one to recommend due to the trade-offs in each. So I delayed adding that section and shaved a rather large yak by writing a third library.
Django’s transaction.on_commit() hook is useful for running tasks that rely on changes in the current database transaction. The database connection enqueues callback functions passed to on_commit, and executes the callbacks after the current transaction commits. If the transaction is rolled back, the callbacks are discarded. This means they act if-and-when the final version of the data is visible to other database connections.
My previously announced book “Speed Up Your Django Tests” is out now on Gumroad. I’ve been writing since the 3rd March, so it’s quite a relief to have launched it.
It’s occasionally useful to be able to tell which Django manage.py command is being run, in a code path that otherwise has no way of telling. For example, in Speed Up Your Django Tests, I describe how to modify manage.py to default use a test settings file when the test command is run.
At the start of March I started writing a blog post called “How to Speed Up Your Django Tests”. Before I knew it, the outline alone was 4,000 words! I realized writing it up would be a major undertaking. As lockdown arrived, I found the time to write it all up.