Django 6.0’daki Yeni Özellikler

 (adamj.eu)
4 puan yazan GN⁺ 2025-12-11 | 1 yorum | WhatsApp'ta paylaş
  • 20 yıldan uzun bir geçmişe sahip Django 6.0, şablonlar, arka plan görevleri, güvenlik, e-posta gibi kritik alanlarda kapsamlı iyileştirmeler yapan büyük bir sürümdür
  • Template partials özelliğiyle şablon içindeki kodun yeniden kullanımı kolaylaşıyor ve htmx gibi araçlarla entegrasyon güçleniyor
  • Tasks framework eklendi; HTTP istek-yanıt döngüsünün dışında arka plan görevleri çalıştırılabiliyor
  • Content Security Policy (CSP) çekirdeğe dahil edildiği için XSS gibi içerik enjeksiyonu saldırılarına karşı koruma kolaylaştı
  • E-posta API modernizasyonu, ORM geliştirmeleri ve varsayılan anahtar genişletmesiyle geliştirici deneyimi ve ölçeklenebilirlik belirgin biçimde arttı

Django 6.0 Genel Bakış

  • Django 6.0, Python web çerçevesinin yeni bir sürümü ve 20 yıllık gelişimin devamıdır
  • Başlıca değişiklikler; şablonlar, arka plan görevleri, güvenlik ve e-posta işleme olmak üzere dört temel alana odaklanır
  • Resmi sürüm notlarında derlenen ana iyileştirmeler, toplulukta çok sayıda katkıcının katılımıyla hazırlanmıştır

django-upgrade aracı

  • Mevcut projeleri Django 5.2 ve altı sürümlerden yükseltirken django-upgrade aracıyla kodu otomatik dönüştürebilirsiniz
  • Django 6.0 için dahil edilen 5 otomatik düzeltici (fixer) vardır ve bazı uyarılar otomatik olarak çözülür

Template partials

  • Şablon içinde parça tanımlama ({% partialdef %}) işlevi eklendi; bu da kod tekrarını azaltıp yeniden kullanımı kolaylaştırır
    • Aynı şablonda tanımlanan bir partial birden çok kez çağrılabilir
    • inline seçeneğiyle tanımlama sırasında render yapmak mümkündür
  • Kısmi render ile yalnızca belirli bir partial bağımsız olarak render edilebilir
    • Örnekte, htmx kullanılarak view_count bölümü periyodik olarak güncellenir
    • URL’ye #partial_name eklenerek yalnızca ilgili bölüm render edilebilir
  • Bu özellik, Google Summer of Code projesi aracılığıyla Django’ya entegre edilmiş ve önceki django-template-partials paketinden evrilmiştir

Tasks framework

  • Django’ya yeni bir arka plan görevlerini çalıştırma framework’ü eklendi
    • HTTP istek-yanıt döngüsünün dışında kod çalıştırılabilir
    • E-posta gönderimi, veri işleme, rapor üretimi gibi asenkron görevlerde kullanılabilir
    Reklam
  • Görevler @task dekoratörü ile tanımlanır, Task.enqueue() ile kuyruğa eklenir
  • Varsayılan backend’ler; geliştirme için ImmediateBackend ve DummyBackend olmak üzere iki tanedir ve
    django-tasks paketindeki DatabaseBackend ile SQL DB tabanlı çalıştırma yapılabilir
  • db_worker komutuyla işçi başlatılır ve günlükler aracılığıyla durum doğrulanabilir
  • Bu özellik, Wagtail’de doğan fikir doğrultusunda, DEP 0014 önerisinin ardından Django’ya entegre edilmiştir

Content Security Policy(CSP) desteği

  • Django 6.0, CSP standardını yerleşik olarak destekleyerek XSS gibi içerik enjeksiyonu saldırılarına karşı savunmayı güçlendirir
    • ContentSecurityPolicyMiddleware’i MIDDLEWARE’e ekleyerek etkinleştirin
    • SECURE_CSP, SECURE_CSP_REPORT_ONLY ayarlarıyla politika yapılandırılabilir
  • Nonce tabanlı güvenlik yerleşiktir ve <script> ve <style> etiketlerine nonce="{{ csp_nonce }}" özniteliği eklenebilir
    • Her istek için rastgele bir nonce üretilir ve yalnızca güvenilir kaynaklar çalıştırılır
  • CSP, 2004’te önerildikten sonra django-csp paketiyle uygulanmış, bu sürümde ise resmi olarak çekirdeğe alınmıştır

E-posta API güncellemesi

  • Django’nun e-posta işleme mantığı Python 3.6’nın modern e-posta API’sine taşındı
    • Dahili olarak email.message.EmailMessage sınıfını kullanır
    • Mevcut send_mail() ve EmailMessage arayüzleri korunmuştur
  • Yeni API, daha az hata, güvenliğin artışı ve satır içi ek ekleri iyileştirme gibi avantajlar sunar
  • MIMEPart nesnesiyle HTML içeriğine görsel gibi satır içi ekler kolayca eklenebilir
  • Bu değişiklik 2024’te önerildi ve 8 aylık geliştirme sonunda birleştirildi
Reklam

E-posta API’sinde konumsal argüman sınırlaması

  • django.core.mail API’sinde bazı parametreler yalnızca anahtar kelime argümanı olarak kabul edilir
    • fail_silently gibi opsiyonel argümanlar konumsal argüman olarak iletilirse uyarı üretilir
    • Bu hamle okunabilirlik ve sürdürülebilirliği artırmak için yapılmıştır
  • django-upgrade aracındaki mail_api_kwargs fixer ile otomatik olarak düzeltilebilir

Shell otomatik import genişletmesi

  • Django 5.2’deki otomatik model import özelliği genişletildi;
    settings, connection, models, functions, timezone gibi öğeler otomatik olarak import ediliyor
  • ./manage.py shell -v 2 komutuyla otomatik import edilenler listelenebilir
  • Geliştirici rahatlığı artar ve tekrarlayan kod azaltılmış olur

ORM geliştirmesi: save() sonrası dinamik alan güncellemesi

  • GeneratedField veya ifade tabanlı alanlar save() sonrasında otomatik güncellenir
    • RETURNING ifadesini destekleyen DB’lerde (SQLite, PostgreSQL, Oracle) anında yansır
    • MySQL ve MariaDB’de gecikmeli yükleme ile otomatik güncelleme yapılır
  • Ek sorgu olmadan en son değerleri doğrudan kullanabilmek verimliliği artırır

Evrensel StringAgg aggregate işlevi

  • StringAgg aggregate fonksiyonu artık tüm veritabanı backendlerinde kullanılabiliyor
    • Giriş değerlerini ayırıcı (delimiter) ile birleştirilen bir string döner
    • PostgreSQL’e özgü bir işlevken artık django.db.models içinde doğrudan kullanılabiliyor
  • Value() ifadesiyle ayırıcı belirtilebilir
Reklam

BigAutoField’ı varsayılanlaştırma

  • DEFAULT_AUTO_FIELD değeri BigAutoField olarak değiştirildi
    • 64 bit tamsayı türü birincil anahtar kullanarak Primary Key tükenmesi sorunu önlenir
    • Yeni projelerde ekstra ayar olmadan otomatik olarak uygulanır
  • Django 3.2’de getirilen ayar, böylece kolaylaştırılarak boilerplate azaltıldı

Şablon iyileştirmeleri

  • forloop.length değişkeni eklendi; döngüde toplam uzunluğa erişilebilir
    • {{ forloop.counter }}/{{ forloop.length }} biçiminde kullanılır
  • querystring şablon etiketleri iyileştirildi
    • Boş mapping verildiğinde ? otomatik eklenerek link davranışı tutarlılaştırıldı
    • Çoklu mapping argümanı birleştirme desteklenerek sorgu parametrelerini birleştirmek kolaylaştı

Sonuç

  • Django 6.0’a 174 katkıcı katıldı ve
    çok sayıda optimizasyon ile hata düzeltmesi içeriyor
  • Yükseltme, genel olarak güvenlik, sürdürülebilirlik ve geliştirici deneyimi (DX) açısından iyileştirme sağlıyor
  • Ek değişiklikler için resmi sürüm notlarına bakılabilir

İlgili okumalar

1 yorum

 
GN⁺ 2025-12-11
Hacker News görüşleri

  • Şirkette birkaç yıldır Django’yu aralıklı olarak kullanıyorum. Genel olarak hoşuma gidiyor ama ORM hâlâ zor geliyor
    Django görüşü güçlü bir framework olduğu için, “Django usulünü” takip etmek gerektiğini ancak şimdi tam olarak anladım.
    Sorun şu ki farklı iş birimlerinin çoklu veritabanlarını yönetmem gerekiyor; bu yüzden her seferinde onların kendine özgü yapısına uyum sağlamakla uğraşıyorum.
    Sonunda managed seçeneğini kapatıp şemayı inspectdb ile içe aktarıyor, ardından web’de görünmesini istemediğim tabloları elle siliyorum.
    Yeni geliştirilen web uygulamaları için Django hâlâ en iyi tercih

    • Katılıyorum. Ama DB migration iş akışı hâlâ zayıf
      Django, şema durumunu kodla birlikte saklamadığı için DB komutları her çalıştırıldığında mevcut durumu tahmin etmek zorunda kalıyor.
      Veritabanı durumunu model koduyla tanımlamanın doğasında sınırlamalar var.
      Ben Rails’teki gibi migration’ları açık DB komutlarıyla kurup modeli onun üzerine oturtan yaklaşımı daha çok seviyorum
    • Django’nun çoklu veritabanı desteğini kullanıp kullanmadığını merak ediyorum
    • Küçük bir projede Aldjemy kullandım; Django ORM ile zor olan karmaşık sorgu birleşimlerini oldukça iyi halletti
    • Django’yu 10 yıldan uzun süredir kullanıyorum; ORM ancak “fena değil” seviyesinde. Bir ara SQLAlchemy’ye geçme eğilimi vardı ama buna değmezdi.
      Manager arayüzü ilk başta kafa karıştırıyor ama migration aracı gerçekten harika
    • ORM üzerinden view veya materialized view tanımlamak performansı ciddi şekilde artırabiliyor.
      Böylece hem SQL tuning esnekliğini hem de Django’nun rahatlığını birlikte elde ediyorsunuz.
      Yalnız bunları migration script’lerinin içinde oluşturmayı unutmamak gerekiyor

  • Django’nun her sürümde biraz daha istikrarlı şekilde gelişmesi gerçekten çok hoşuma gidiyor.
    Özellikle 6.0 sürümü faydalı özelliklerle dolu olduğu için ilgi çekici.
    Güvenilir teknolojinin sıkıcı olduğu iddiası yanlış. Doğru gelişim tam da böyle olur

    • Ben de pre-1.0 döneminden beri kullanıyorum ve hâlâ seviyorum.
      Şu anda Django’nun doğduğu yere yakın yaşıyorum.
      Bu arada dünden beri iş arıyorum; tecrübeli bir Django geliştiricisi arıyorsanız ulaşın (oldspiceap@gmail.com)

  • Adam’ın yazdığı kodlar ve blog yazıları her zaman okumaya değer.
    tasks framework’ünün bundan sonra nasıl gelişeceğini merak ediyorum.
    Yalnız harika Django-Q2’nin Celery ile birlikte anılması biraz üzücü

    • Yazarı benim. Güzel sözler için teşekkürler; Celery’den sadece popüler olduğu için bahsettim ;)
    • Celery mükemmel değil ama en iyi seçenek.
      Hataları çok ama kullanıcı tabanı o kadar büyük ki bir sorunla ilk kez karşılaşan kişi olmanız nadir.
      Celery + RabbitMQ ile günde on milyonlarca mesajı sorunsuz işledim.
      Hâlâ ilk bakılması gereken çözüm
    • Yıllardır Celery kullanıyorum; neyin sorunlu olduğunu ve Django Q2’nin bunu nasıl iyileştirdiğini merak ediyorum.
      Başka stack’lerde Kafka da kullanıyorum ama o tamamen farklı ölçekte kullanım senaryoları için
    • Celery’ye neden “korkunç” dendiğini merak ediyorum

  • Django’yu yaklaşık 5-6 yıldır kullanıyorum; “batteries included” avantajı açık ama genel olarak ağır hissettiriyor

  • Template partial özelliği güzel görünüyor.
    React’in popüler olmasının nedenlerinden biri kodun yeniden kullanılabilirliği ve sanki Django da o yöne gidiyor

    • React’te yeniden kullanılabilirlik ve bileşebilirliğin özü template değil, her şeyin fonksiyon olması
    • Bu özellik özellikle HTMX ile birlikte kullanıldığında çok değerli. HTMX çok sayıda partial template gerektiriyor
    • React, basit template’lerden ziyade durumu kapsülleyen bileşenler sunuyor
    • Ben de Django 6’yı test ederken blogumda partial kullandım
      Örnek için şuradaki koda bakabilirsiniz
    • Django’nun böyle bir özelliği ancak 2025’te eklemiş olması şaşırtıcı

  • Ben daha çok Odoo kullanıyorum ama Django ve Celery ile de biraz çalıştım.
    Odoo’nun OCA queue modülünü yoğun kullanan biri olarak,
    Django’nun neden Postgres LISTEN/NOTIFY özelliğinden yararlanmadığını hep merak etmişimdir.
    Muhtemelen Django ekosistemine yeterince aşina olmadığım içindir

  • Template Partials ve HTMX, Django’nun Rails View Components + Stimulus versiyonu gibi hissettiriyor.
    Tasks özelliğinin resmi olarak desteklenmesi de sevindirici

    • Rails’te partial rendering’e resmî kılavuzdan bakılabilir
    • Production’da Tasks kullanmak için django-tasks’ı da birlikte kullanmak gerekip gerekmediğini merak ediyorum

  • Django’yu 1.x döneminde, ORM’nin olmadığı zamanlardan beri kullanıyorum.
    Task çalıştırma özelliğinin ancak şimdi eklenmiş olması gerçekten şaşırtıcı.
    Bunu eleştiri olarak söylemiyorum; sadece ilginç bir evrim

    • Aslında bu ferahlatıcı. Django özellikleri acele etmeden, düzgün şekilde uygular.
      Her özelliği yeterince olgunlaştıktan sonra dahil eder ve LTS ile API kararlılığına odaklanır.
      Bu sayede yeni sürüm çıktığında tüm uygulamayı baştan yazmak neredeyse hiç gerekmez
    • Aslında Django 0.95 sürümünden beri ORM içeriyordu.
      O zamanlar daha basitti ama oldukça uzun süre raw SQL kullanmaya gerek kalmadı

  • Ek tartışma bu başlıkta sürüyor

  • Django ve HTMX’i birlikte kullanırken bileşen bazlı template’ler çok rahatsız edici geldiği için,
    Python tabanlı bir bileşen kütüphanesi olan Compone’u kendim yaptım.
    Yalnızca Django’da değil, tüm Python web framework’lerinde kullanılabiliyor ve çok daha konforlu bir geliştirme deneyimi sunuyor