Python: fix SyntaxWarning: '<type>' object is not callable
Take this code, which we want to return a list of shopping items with desired quantities:
(All tags.)
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. 🙂
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.
Imagine you have some Django views using the same two decorators:
Python’s decimal module has concept of a “context”. This defines the default precision of new Decimals, how rounding works, and lots of other behaviour. Maths gets complicated!
Django’s default settings file has always included a BASE_DIR pseudo-setting. I call it a “pseudo-setting” since it’s not read by Django itself. But it’s useful for configuring path-based settings, it is mentioned in the documentation, and some third party packages use it.
I’ve just moved all my open source repositories from using plain pip to python -m pip, in test scripts and documentation.
Here’s a little Python problem I encountered recently.
SyntaxWarning: "is" with a literalTake this reasonable-looking code:
Here’s a hint I have found myself repeating in code review. I learnt this from my university lecturer Tony Field, who probably repeated it in every lecture! He was teaching us Haskell, but it applies to Python, and most other programming languages.
Bruno Oliveira, known for his work on the pytest project, tweeted this thread last July:
pytest is quickly becoming the “standard” Python testing framework. However it can be overwhelming to new users.
Take this code:
datetime modulePython’s datetime module risks a whole bunch of name confusion:
On several Django projects I’ve worked on, there has been a requirement for performing database modifications beyond Django migrations. For example:
One thing I often ask for in code review is conversion of tuples to lists. For example, imagine we had this Django admin class:
If the title worried you about my mental state, you can relax. It’s about the Python code formatter Black!
PyLondinium ran for the second time last weekend. It’s a three day conference from Friday to Sunday, held in central London at the Bloomberg office.
My library apig-wsgi bridges between AWS API Gateway’s JSON format for HTTP requests and Python WSGI applications. Recently Théophile Chevalier opened an issue requesting the library add an extra WSGI environ variable. I closed it by pointing out that it’s not much code to add a custom WSGI middleware to do so (plus the exact key is a bit out of scope for the library).
This is a recipe I’ve used on a number of projects. It combines pytest fixtures with Botocore’s Stubber for an easy testing experience of code using Boto3. (Botocore is the library behind Boto3.)