Neue Funktionen von Django 6.0

• Django 6.0 feiert das 20-jährige Bestehen des Frameworks und ist ein bedeutendes Release mit umfangreichen Verbesserungen in zentralen Bereichen wie Templates, Hintergrundaufgaben, Sicherheit und E-Mail-Verarbeitung.
• Mit Template partials ist die Codewiederverwendung in Templates deutlich einfacher geworden und die Integration mit Tools wie htmx wurde verbessert.
• Ein neues Tasks Framework wurde eingeführt, um Hintergrundaufgaben außerhalb des HTTP-Anfrageantwort-Zyklus auszuführen.
• Mit der eingebauten Content Security Policy (CSP)-Unterstützung wird der Schutz vor Content-Injection-Angriffen wie XSS deutlich vereinfacht.
• Durch die Modernisierung der E-Mail-API, ORM-Optimierungen und die Erweiterung des Primärschlüssels wurden die Entwicklererfahrung und Skalierbarkeit stark verbessert.

---

Überblick zu Django 6.0

• Django 6.0 ist eine neue Version des Python-Webframeworks und setzt 20 Jahre Entwicklung fort.
• Die wichtigsten Änderungen konzentrieren sich auf vier Kernbereiche: Templates, Hintergrundaufgaben, Sicherheit und E-Mail-Verarbeitung.
• Die Veröffentlichung basiert auf Beiträgen zahlreicher Community-Mitwirkender und den zentralen Verbesserungen aus den offiziellen Release Notes.

Das django-upgrade-Tool

• Beim Upgrade bestehender Projekte von Django 5.2 oder älter kann das django-upgrade-Tool für eine automatische Codeumstellung genutzt werden.
• Django 6.0 enthält fünf automatische Fixer und behebt so einige Warnungen automatisch.

Template partials

• Das neue Feature Template-Teildefinition ({% partialdef %}) reduziert Duplikate im Template-Code und verbessert die Wiederverwendbarkeit.
  • Ein im selben Template definiertes Partial kann mehrfach aufgerufen werden.
  • Mit der Option inline kann die Definition direkt beim Rendern erfolgen.
• Über Teil-Rendering kann nur ein bestimmter Partial unabhängig gerendert werden.
  • Im Beispiel wird der Abschnitt view_count mit htmx periodisch aktualisiert.
  • Durch Anhängen von #partial_name an die URL lässt sich nur ein bestimmter Teil rendern.
• Dieses Feature wurde über das Google Summer of Code-Projekt in Django integriert und basiert auf dem bisherigen Paket django-template-partials.

Tasks Framework

• Django erhält ein neues Task-Framework für die Ausführung von Hintergrundaufgaben.
  • Code kann außerhalb des HTTP-Anfrageantwort-Zyklus ausgeführt werden.
  • Einsatzmöglichkeiten sind etwa E-Mails senden, Daten verarbeiten oder Berichte erstellen.
• Aufgaben werden mit dem @task-Decorator definiert und über Task.enqueue() in eine Queue eingereiht.
• Standardmäßig stehen zwei Backends zur Verfügung: ImmediateBackend und DummyBackend für die Entwicklung.
  • Für django-tasks-Pakete kann mit DatabaseBackend eine Ausführung auf Basis einer SQL-Datenbank genutzt werden.
• Mit dem Befehl db_worker wird ein Task-Worker gestartet; der Fortschritt ist über Logs einsehbar.
• Die Idee stammt aus Wagtail und wurde nach dem Vorschlag DEP 0014 in Django übernommen.

Support für Content Security Policy (CSP)

• Django 6.0 unterstützt den CSP-Standard nativ, wodurch der Schutz vor Content-Injection-Angriffen wie XSS deutlich verbessert wird.
  • Durch Hinzufügen von ContentSecurityPolicyMiddleware zu MIDDLEWARE wird CSP aktiviert.
  • Die Einstellungen SECURE_CSP und SECURE_CSP_REPORT_ONLY ermöglichen die Konfiguration von Richtlinien.
• Durch nonce-basierte Sicherheit kann bei <script>- und <style>-Tags automatisch nonce="{{ csp_nonce }}" gesetzt werden.
  • Für jede Anfrage wird ein zufälliger Nonce erzeugt, sodass nur vertrauenswürdige Ressourcen ausgeführt werden.
• CSP wurde nach einem Vorschlag von 2004 über das Paket django-csp umgesetzt und ist mit dieser Version nun offiziell integriert.

Update der E-Mail-API

• Die E-Mail-Verarbeitung in Django wurde auf eine moderne Python-3.6-E-Mail-API umgestellt.
  • Intern kommt dabei die Klasse email.message.EmailMessage zum Einsatz.
  • Bestehende send_mail()- und EmailMessage-Schnittstellen bleiben erhalten.
• Die neue API reduziert Fehler, verbessert die Sicherheit und verbessert die Verarbeitung von Inline-Anhängen.
• Mit dem Objekt MIMEPart lassen sich Inline-Anhänge wie Bilder in HTML-Inhalten einfach hinzufügen.
• Diese Änderung wurde 2024 vorgeschlagen und nach acht Monaten Entwicklung zusammengeführt.

Einschränkung von Positionsargumenten in der E-Mail-API

• In der django.core.mail-API wurden einige Parameter auf nur benannte Argumente (Keyword-Only) umgestellt.
  • Wird ein optionales Argument wie fail_silently als Positionsargument übergeben, erscheint eine Warnung.
  • Das dient der besseren Lesbarkeit und Wartbarkeit.
• Das mail_api_kwargs-Fixer-Tool von django-upgrade kann die Anpassung automatisch übernehmen.

Erweiterter automatischer Import in der Shell

• Die automatische Modellimport-Funktion aus Django 5.2 wurde erweitert, sodass jetzt auch settings, connection, models, functions und timezone automatisch importiert werden.
• Mit ./manage.py shell -v 2 lässt sich die Liste der automatisch importierten Module anzeigen.
• Dadurch verbessert sich die Entwicklerfreundlichkeit und wiederholender Code wird reduziert.

ORM-Verbesserung: Dynamische Feldaktualisierung nach save()

• GeneratedField- und ausdrucksbasierte Felder werden nach einem save() automatisch aktualisiert.
  • In Datenbanken mit RETURNING-Unterstützung (SQLite, PostgreSQL, Oracle) geschieht das sofort.
  • In MySQL und MariaDB erfolgt die Aktualisierung per Lazy Loading.
• Damit lassen sich aktuelle Werte sofort nutzen, ohne zusätzliche Abfragen zu senden.

Universelle StringAgg-Aggregatfunktion

• Die StringAgg-Aggregate ist jetzt auf allen Datenbank-Backends verfügbar.
  • Sie gibt einen String mit Trennzeichen (delimiter) als Verbindung der Eingabewerte zurück.
  • Die Funktion war zuvor auf PostgreSQL beschränkt, kann jetzt aber direkt aus django.db.models genutzt werden.
• Der Trennzeichenwert lässt sich mit dem Ausdruck Value() angeben.

BigAutoField als Standard

• Der Standardwert von DEFAULT_AUTO_FIELD wurde auf BigAutoField geändert.
  • Durch 64-Bit-Ganzzahl-Primärschlüssel wird das Risiko von Primärschlüsselengpässen reduziert.
  • In neuen Projekten wird dies automatisch angewendet.
• Die Konfiguration, die in Django 3.2 eingeführt wurde, wurde vereinfacht, wodurch weniger Boilerplate-Code nötig ist.

Template-Verbesserungen

• Die Variable forloop.length wurde ergänzt, sodass die Gesamtlänge einer Schleife direkt abrufbar ist.
  • Einsatzbeispiel: {{ forloop.counter }}/{{ forloop.length }}
• Verbesserungen am querystring-Template-Tag.
  • Bei leerem Mapping wird automatisch ? ergänzt, damit sich Links konsistent verhalten.
  • Die Kombination mehrerer Mapping-Argumente wird unterstützt, wodurch Query-Parameter leichter zusammengesetzt werden können.

Abschluss

• An Django 6.0 haben 174 Mitwirkende teilgenommen.
• Außerdem sind zahlreiche Optimierungen und Fehlerbehebungen enthalten.
• Das Upgrade verbessert übergreifend Sicherheit, Wartbarkeit und Entwicklererfahrung (DX).
• Zusätzliche Änderungen sind in den offiziellen Release Notes dokumentiert.

[GN⁺]

Hacker-News-Kommentare

• Ich nutze Django im Unternehmen seit einigen Jahren immer wieder sporadisch. Insgesamt gefällt es mir, aber das ORM fühlt sich immer noch schwerfällig an
  Django ist ein meinungsstarkes Framework, und erst jetzt habe ich wirklich verstanden, dass man dem „Django-Weg“ folgen muss.
  Das Problem ist, dass ich mit mehreren Datenbanken aus verschiedenen Geschäftsbereichen arbeiten muss und jedes Mal mit deren Eigenheiten kämpfe.
  Am Ende schalte ich managed aus, hole das Schema mit inspectdb und lösche dann manuell die Tabellen, die ich nicht im Web verfügbar machen möchte.
  Für neu entwickelte Web-Apps ist Django aber immer noch die beste Wahl

  • Stimme zu. Aber der DB-Migrations-Workflow ist immer noch etwas enttäuschend
    Django speichert den Schema-Zustand nicht zusammen mit dem Code, daher muss bei jedem Ausführen von DB-Befehlen der aktuelle Zustand neu hergeleitet werden.
    Den DB-Zustand über Model-Code zu definieren hat grundsätzlich Grenzen.
    Ich bevorzuge eher den Rails-Ansatz, bei dem Migrationen aus expliziten DB-Befehlen bestehen und die Models darauf aufsetzen
  • Ich frage mich, ob du Djangos Unterstützung für mehrere Datenbanken verwendest
  • Ich habe in einem kleinen Projekt Aldjemy ausprobiert, und es hat komplexe Query-Kombinationen, die mit dem Django ORM schwer umzusetzen sind, ziemlich gut gelöst
  • Ich arbeite seit über 10 Jahren mit Django, und das ORM ist so „ganz okay“. Es gab mal eine Bewegung, auf SQLAlchemy umzusteigen, aber das war es nicht wert.
    Das Manager-Interface ist anfangs verwirrend, aber das Migrationstool ist wirklich hervorragend
  • Wenn man über das ORM Views oder materialized views einrichtet, hilft das enorm bei der Performance.
    So bekommt man zugleich die Flexibilität von SQL-Tuning und den Komfort von Django.
    Man darf nur nicht vergessen, sie in den Migrationsskripten anzulegen

• Mir gefällt sehr, dass Django mit jedem Release stetig weiter verbessert wird.
  Besonders Version 6.0 ist interessant, weil sie viele nützliche Funktionen enthält.
  Es stimmt einfach nicht, dass verlässliche Technik langweilig ist. Genau so sollte Weiterentwicklung aussehen

  • Ich nutze es auch seit der Zeit vor 1.0 und mag es immer noch.
    Ich wohne inzwischen in der Nähe des Ortes, an dem Django entstanden ist.
    Und nebenbei: Seit gestern bin ich auf Jobsuche, also meldet euch gern, wenn ihr einen erfahrenen Django-Entwickler sucht ([e-mail])

• Code oder Blogposts von Adam sind immer lesenswert.
  Ich bin gespannt, wie sich das Tasks-Framework weiterentwickeln wird.
  Etwas schade finde ich nur, dass das großartige Django-Q2 zusammen mit Celery erwähnt wurde

  • Ich bin der Autor. Danke für das Lob, und Celery wurde nur wegen seiner Popularität erwähnt ;)
  • Celery ist nicht perfekt, aber die beste verfügbare Option.
    Es hat viele Bugs, aber die Nutzerschaft ist so groß, dass man nur selten der Erste mit einem Problem ist.
    Ich habe mit der Kombination aus Celery + RabbitMQ zuverlässig zig Millionen Nachrichten pro Tag verarbeitet.
    Es ist immer noch eine der ersten Lösungen, die man sich ansehen sollte
  • Ich habe Celery viele Jahre verwendet und würde gern wissen, was genau das Problem war und wie Django Q2 das verbessert.
    In anderen Stacks nutzen wir auch Kafka, aber das ist ein Anwendungsfall auf einem ganz anderen Niveau
  • Ich frage mich, warum Celery als „schrecklich“ bezeichnet wird

• Ich nutze Django seit etwa 5 bis 6 Jahren, und der Vorteil „batteries included“ ist zwar eindeutig, aber insgesamt fühlt es sich schwergewichtig an

• Die Template-Partial-Funktion sieht gut aus.
  Einer der Gründe, warum React populär wurde, ist Code-Wiederverwendbarkeit, und Django scheint sich ebenfalls in diese Richtung zu bewegen

  • Der Kern von Reacts Wiederverwendbarkeit und Kompositionsfähigkeit sind nicht Templates, sondern dass alles Funktionen sind
  • Diese Funktion ist besonders zusammen mit HTMX sehr wertvoll. HTMX braucht viele Partial-Templates
  • React bietet nicht einfach nur Templates, sondern Komponenten, die Zustand kapseln
  • Ich habe beim Testen von Django 6 ebenfalls Partials in meinem Blog verwendet
    Ein Beispiel ist hier im Code zu sehen
  • Ich finde es erstaunlich, dass Django so eine Funktion erst 2025 hinzugefügt hat

• Ich arbeite hauptsächlich mit Odoo, habe aber auch etwas mit Django und Celery gemacht.
  Als jemand, der das OCA queue module in Odoo viel nutzt,
  habe ich mich immer gefragt, warum Django nicht die LISTEN/NOTIFY-Funktion von Postgres nutzt.
  Vielleicht liegt das einfach daran, dass ich mit dem Django-Ökosystem nicht vertraut genug bin

• Template Partials und HTMX fühlen sich wie Djangos Version von Rails View Components + Stimulus an.
  Es ist auch schön zu sehen, dass Tasks offiziell unterstützt werden

  • Das Rendern von Partials in Rails kann man in der offiziellen Anleitung sehen
  • Ich frage mich, ob man für Tasks im Produktiveinsatz zusätzlich auch django-tasks verwenden muss

• Ich nutze Django seit der 1.x-Zeit, noch aus der Zeit ohne ORM.
  Dass jetzt erst eine Task-Ausführung eingebaut wird, überrascht mich wirklich.
  Das ist keine Kritik, nur eine interessante Entwicklung

  • Ich finde das eher erfrischend. Django überstürzt Features nicht, sondern setzt sie ordentlich um.
    Jede Funktion wird erst aufgenommen, wenn sie ausreichend erprobt ist, und der Fokus liegt auf LTS und API-Stabilität.
    Deshalb muss man beim Erscheinen einer neuen Version fast nie die ganze App neu schreiben
  • Tatsächlich hatte Django seit Version 0.95 ein ORM.
    Damals war es noch einfach, aber man musste schon ziemlich lange kein raw SQL mehr schreiben

• Die weitere Diskussion geht in diesem Thread weiter

• Weil mir bei Django + HTMX komponentenbasierte Templates viel zu umständlich waren,
  habe ich selbst die Python-basierte Komponentenbibliothek Compone gebaut.
  Sie funktioniert nicht nur mit Django, sondern mit allen Python-Web-Frameworks und bietet eine deutlich angenehmere Developer Experience