Собрали в одном месте самые важные ссылки
читайте авторский блог
Django's async capabilities have significantly improved, making it a viable option for production use, especially in AI applications where I/O-bound tasks are prevalent.
Без четкого понимания того, как построены шаблоны и используемые классы любая попытка кастомизации превращается в пытку. Этот цикл статей — моя попытка помочь понять и полюбить то, как всё устроено изнутри. Тема длинная, так что начнем с самых азов. Сейчас мы разберем все основные шаблоны и механизм их поиска.
A streamlined and cost-effective approach that uses Docker and customizable health checks.
Learn how to achieve zero downtime in Django deployments with blue-green strategies and multi-step database migrations to handle backward-incompatible changes effectively.
Аутентификация является фундаментальной частью любого веб-приложения. Мы рассмотрим различные способы реализации аутентификации в Django, начиная от стандартных методов и заканчивая более крутыми техниками, например как 2FA и OAuth2.
A very comprehensive tutorial on Celery, what it is, how to use it in Django projects, and several examples of different Celery tasks.
Проводя аудиты процессов разработки ПО, мы часто слышим, что функционал реализован во фреймворке, и это может вызывать вопросы со стороны безопасников. Python, будучи одним из популярных языков программирования, предлагает множество фреймворков, каждый из которых должен быть защищен и иметь встроенные механизмы безопасности либо возможности для встраивания этих механизмов. В этой статье попробуем разобраться, какие возможности действительно предоставляют фреймворки, рассмотрим механизмы безопасности и способы их настройки на примере распространенных фреймворков: Django, FastAPI и Flask.
Django co-creator Simon Willison wrote a live blogging app for OpenAI's DevDay event.
A take on what could be a project template for Django advanced usage, with modern tooling (for Python and UI dependencies, as well as configuration/environment management), but not too opinionated.
Django provides us with a rich set of view decorators. In this post, we’ll look at a technique for hoisting repeated use of these decorators to reduce repetition. Repeated @cache_control calls Here are two public views with the same @cache_control decorator: from django.views.decorators.cache import cache_control @cache_control(max_age=60 * 60, public=True) def about(request): ... @cache_control(max_age=60 * 60, public=True) def contact_us(request): ... To avoid this repetition, we can call cache_control once at the top of the module and use that result as the decorator: from django.views.decorators.cache import cache_control cache_public = cache_control(max_age=60 * 60, public=True) @cache_public def about(request): ... @cache_public def team(request): ... This works because cache_control is technically not a decorator but a function that returns a decorator. So we can separate the call of cache_control from the decorating. Aside from reducing redundant repetition, this technique also saves a tiny bit of time and memory when importing the module, because cache_control is only called once. Repeated @require_http_methods calls Here’s another example, instead using @require_http_methods: from django.views.decorators.http import require_http_methods require_GET_POST = require_http_methods(("GET", "POST")) @require_GET_POST def contact_us(request): ... @require_GET_POST def store_feedback(request): ... (Actually, it would be neat if Django provided require_GET_POST out of the box…) Hoisting @method_decorator calls for class-based views This technique is particularly beneficial for class-based views, where view decorators mostly need extra wrapping with method_decorator: from django.utils.decorators import method_decorator from django.views.decorators.cache import cache_control from django.views.generic import TemplateView cache_public = method_decorator(cache_control(max_age=60 * 60, public=True)) @cache_public class AboutView(TemplateView): ... @cache_public class TeamView(TemplateView): ... I also like to use this technique with decorators that don’t take arguments, such as the new @login_not_required from Django 5.1: from django.contrib.auth.decorators import login_not_required from django.utils.decorators import method_decorator from django.views.generic import TemplateView login_not_required_m = method_decorator(login_not_required, name="dispatch") @login_not_required_m class AboutView(TemplateView): ... @login_not_required_m class TeamView(TemplateView): ... I like adding an “m” suffix to the variable name to indicate that it’s a method decorator version of the original. Test decorators This deduplication technique can also dramatically improve test readability, where many tests often need the same decorator applied. For example, third-party apps may mark version-restricted tests with unittest’s @skipIf or pytest’s @pytest.mark.skipif: from unittest import skipIf import django django_5_1_plus = skipIf(django.VERSION < (5, 1), "Django 5.1+ required") class AcmeAuthMiddlewareTests(TestCase): ... @django_5_1_plus def test_view_login_not_required(self): ... @django_5_1_plus def test_view_login_required(self): ... Fin May your decorators be DRYer than the Kalahari, —Adam
Тестировать монолитное приложение может быть непросто — особенно, когда сервис активно развивается. На проверку каждой фичи уходит всё больше ресурсов, а времени на оптимизацию мало. Как поступить?