Curlylint is an HTML linter for “curly braces” templates, and their HTML. It focuses on rules to check for common accessibility issues
Grab Curlylint from PyPI, and start linting your HTML templates:
# Assuming you’re using Python 3.6+, pip install curlylint # Then run: curlylint my/templates
The quest to add “hybrid” asynchronous support to Django - where it can run both synchronous and asynchronous code - is a long one.
Django 3.1 reached an important milestone with synchronous and asynchronous views, and now the next big step is to take a long, hard look at the thing that makes up over half the Django codebase: the ORM .
The ORM is gigantic, old, and complex - and has an API designed and tweaked over many years.
We’ll look at some of those design decisions and how they reflect in the world of async, the challenges that underlie a hybrid API, as well as how the safety-first nature of the ORM has to evolve to deal with new and exciting async ways of breaking things.
We’ll also dive into what it means to have asynchronous database backends, and how support for those are progressing in the Python world - and how we’re trying to ship something that’s useful before fully asynchronous database APIs are done.
Python, PyCon, PyConAU, PyConline
Fri Sep 4 17:10:00 2020
When we write custom management commands, it’s easy to write integration tests for them with call_command() .
This allows us to invoke the management command as it runs under manage.py, and retrieve the return code, standard output, and standard error.
It’s great, but has some overhead, making our tests slower than necessary. If we have logic separated out of the command’s handle() method, it improves both readability and testability, as we can unit test it separately.
For those not familiar…
CBVs have more of a learning curve .
However, then they are –to my mind– easier to reason about than a FBV. I don’t like views that are long. But I’m not dogmatic about it and neither are most Django devs I know. If it works, it works :)