Django 6.0 की नई सुविधाएँ

 (adamj.eu)
4 पॉइंट द्वारा GN⁺ 2025-12-11 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Django 6.0 ने 20वें वर्ष में प्रवेश करते हुए templates, background tasks, सुरक्षा और email जैसे कोर क्षेत्रों में बड़ा सुधार करने वाली एक प्रमुख रिलीज दी है
  • Template partials फीचर से templates के अंदर code reuse आसान हो गया है और htmx जैसे टूल्स के साथ integration मजबूत हुई है
  • नया Tasks framework HTTP request-response चक्र के बाहर background tasks चलाने की सुविधा देता है
  • Content Security Policy (CSP) डिफ़ॉल्ट रूप से मौजूद है, जिससे XSS जैसी content injection attacks से बचाव आसान हो गया है
  • email API modernization, ORM सुधार और प्राथमिक कुंजी (primary key) विस्तार के साथ डेवलपर अनुभव और स्केलेबिलिटी में बड़ा सुधार हुआ है

Django 6.0 का अवलोकन

  • Django 6.0 Python web framework की नई रिलीज है, जो 20 साल की विकास-यात्रा को आगे बढ़ाती है
  • मुख्य बदलाव template, background task, security और email handling पर केंद्रित चार कोर क्षेत्रों के इर्द-गिर्द हैं
  • इसे समुदाय के कई contributors ने develop किया और आधिकारिक रिलीज़ नोट्स पर आधारित मुख्य सुधार सूचीबद्ध किए गए हैं

django-upgrade टूल

  • अगर कोई परियोजना Django 5.2 या उससे नीचे से Django 6.0 पर अपग्रेड कर रहा हो, तो django-upgrade टूल की मदद से code बदलना स्वचालित तरीके से किया जा सकता है
  • Django 6.0 से संबंधित 5 auto-fixer शामिल हैं, जो कुछ warnings को अपने-आप ठीक कर देते हैं

Template partials

  • टेम्पलेट पार्टियल डिफ़िनिशन ({% partialdef %}) फीचर जोड़ा गया है, जिससे टेम्पलेट में दोहराए गए code को कम करके reuse करना आसान होता है
    • एक ही template के अंदर define किए गए partial को कई बार call किया जा सकता है
    • inline विकल्प के साथ define करने के साथ-साथ तुरंत render भी किया जा सकता है
  • Partial rendering से केवल चुनिंदा partial को अलग से render किया जा सकता है
    • उदाहरण में htmx की मदद से view_count भाग को periodic तरीके से अपडेट किया गया है
    • URL में #partial_name जोड़ने से केवल वही भाग render होता है
  • यह फीचर Google Summer of Code के माध्यम से Django में जोड़ा गया और पहले के django-template-partials पैकेज से विकसित हुआ

Tasks फ्रेमवर्क

  • Django में नया Tasks framework जोड़ा गया है ताकि code को HTTP request-response cycle के बाहर execute किया जा सके
    • email भेजना, data processing और report generation जैसी asynchronous tasks के लिए उपयोगी
  • @task decorator से task define करें और Task.enqueue() से queue में add करें
  • default backends के रूप में development के लिए ImmediateBackend और DummyBackend उपलब्ध हैं,
    जबकि django-tasks पैकेज का DatabaseBackend इस्तेमाल करने पर SQL DB-based execution संभव होता है
  • db_worker command से task worker चलाया जाता है, और logs से status check किया जा सकता है
  • इस फीचर की शुरुआत Wagtail से हुई थी; DEP 0014 proposal के बाद इसे Django में merge किया गया

Content Security Policy (CSP) सपोर्ट

  • Django 6.0 में CSP standard बिल्ट-इन होने से XSS जैसी content injection attacks से सुरक्षा बेहतर होती है
    • ContentSecurityPolicyMiddleware को MIDDLEWARE में जोड़कर इसे enable करें
    • SECURE_CSP, SECURE_CSP_REPORT_ONLY सेटिंग्स से policy configure की जा सकती है
  • Nonce-based security अंतर्निहित है, जिससे <script> और <style> टैग में nonce="{{ csp_nonce }}" attribute जोड़ा जा सकता है
    • हर request पर random nonce generate होता है और केवल trusted resources ही execute होते हैं
  • CSP का प्रस्ताव 2004 में आया था, और तब से यह django-csp package के रूप में implement होता रहा; इस संस्करण में यह official बन गया है

Email API अपडेट

  • Django की email handling logic को Python 3.6 की modern email API पर migrate किया गया है
    • अंदर से email.message.EmailMessage class का इस्तेमाल होता है
    • मौजूदा send_mail() और EmailMessage interfaces को जस का तस रखा गया है
  • नया API bug कम करने, security बेहतर करने और inline attachment handling सुधारने में मदद करता है
  • MIMEPart object से HTML body में image जैसे inline attachments आसानी से add किए जा सकते हैं
  • यह बदलाव 2024 में प्रस्तावित होकर लगभग 8 महीने development के बाद merge हुआ

Email API में position-only argument प्रतिबंध

  • django.core.mail API में कुछ parameters को केवल keyword arguments के रूप में ही स्वीकार करने के लिए बदल दिया गया है
    • fail_silently जैसे optional arguments को positional के रूप में देने पर warning आती है
    • यह बदलाव readability और maintainability बेहतर करने के लिए किया गया है
  • django-upgrade के mail_api_kwargs fixer से इसे auto-fix किया जा सकता है

Shell auto-import विस्तार

  • Django 5.2 की auto model import सुविधा का विस्तार करते हुए अब
    settings, connection, models, functions, timezone को भी auto-import किया जाता है
  • ./manage.py shell -v 2 से auto import list देखी जा सकती है
  • इससे developer productivity बढ़ती है और बार-बार वही code लिखने की जरूरत घटती है

ORM सुधार: save() के बाद dynamic field refresh

  • GeneratedField या expression-based fields अब save() के बाद auto-update हो जाते हैं
    • SQLite, PostgreSQL, Oracle जैसे DB जहाँ RETURNING clause supported है, वहाँ तुरंत sync हो जाता है
    • MySQL और MariaDB में यह delayed loading के साथ update होता है
  • अतिरिक्त query के बिना तुरंत latest value available होने से efficiency बढ़ती है

Universal StringAgg aggregate function

  • StringAgg aggregate अब सभी database backends पर उपलब्ध है
    • यह input values को delimiter से join करके string वापस करता है
    • पहले यह PostgreSQL-specific था, लेकिन अब सीधे django.db.models से उपयोग हो सकता है
  • delimiter देने के लिए Value() expression उपयोग किया जा सकता है

BigAutoField को default बनाना

  • DEFAULT_AUTO_FIELD की default value अब BigAutoField कर दी गई है
    • 64-bit integer primary key use होने से Primary Key exhaustion की समस्या से बचाव होता है
    • नए projects में अलग सेटिंग किए बिना यह स्वतः लागू होता है
  • Django 3.2 में लाई गई सेटिंग को simplify करके boilerplate को कम किया गया है

Template सुधार

  • forloop.length variable जोड़ी गई है, जिससे loop की कुल लंबाई सीधे reference की जा सकती है
    • उदाहरण: {{ forloop.counter }}/{{ forloop.length }}
  • querystring टेम्पलेट टैग में सुधार
    • खाली mapping होने पर लिंक consistency के लिए ? auto-add होता है
    • कई mapping arguments merge करने का समर्थन जिससे query parameters combine करना आसान होता है

निष्कर्ष

  • Django 6.0 में कुल 174 contributors शामिल थे,
    और इसमें कई optimizations तथा bug fixes शामिल हैं
  • अपग्रेड करने पर security, maintainability और डेवलपर अनुभव (DX) व्यापक रूप से बेहतर हो जाते हैं
  • अतिरिक्त बदलावों के लिए official रिलीज़ नोट्स देखें

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-12-11
Hacker News की राय

  • मैं कई सालों से कंपनी में Django का बीच-बीच में इस्तेमाल करता आ रहा हूँ। कुल मिलाकर पसंद है, लेकिन ORM अब भी मुश्किल लगता है
    अब जाकर समझ आया है कि Django एक opinionated framework है, इसलिए आपको ‘Django way’ का पालन करना पड़ता है।
    दिक्कत यह है कि मुझे अलग-अलग बिज़नेस डिपार्टमेंट्स के multiple databases संभालने पड़ते हैं, इसलिए हर बार उनकी अजीब खासियतों से जूझना पड़ता है।
    आखिर में मैं managed बंद करके inspectdb से schema इम्पोर्ट करता हूँ, फिर जिन tables को web पर expose नहीं करना चाहता उन्हें हाथ से हटा देता हूँ।
    नए web apps के लिए Django अब भी सबसे अच्छा विकल्प है

    • सहमत हूँ। लेकिन DB migration workflow अब भी कमजोर लगता है
      Django code के साथ schema state स्टोर नहीं करता, इसलिए हर बार DB command चलाते समय उसे मौजूदा state का अंदाज़ा लगाना पड़ता है।
      model code से DB state को define करना मूल रूप से सीमित है।
      मैं Rails की तरह explicit DB commands से migrations बनाना, और उसके ऊपर models रखना ज़्यादा पसंद करता हूँ
    • जिज्ञासा है कि क्या आप Django की multiple database support का इस्तेमाल कर रहे हैं
    • मैंने छोटे प्रोजेक्ट्स में Aldjemy इस्तेमाल किया है, इसने Django ORM से मुश्किल complex query combinations को काफ़ी अच्छी तरह संभाला
    • मैं 10 साल से ज़्यादा समय से Django इस्तेमाल कर रहा हूँ, और ORM बस ‘ठीक-ठाक’ है। एक समय SQLAlchemy पर जाने की बात चली थी, लेकिन उतना फ़ायदा नहीं था।
      Manager interface शुरू में उलझाता है, लेकिन migration tool वाकई शानदार है
    • ORM के ज़रिए views या materialized views सेट कर दें तो performance में काफ़ी मदद मिलती है।
      इससे SQL tuning की flexibility और Django की सुविधा दोनों मिल जाती हैं।
      बस यह याद रखना चाहिए कि इन्हें migration script के अंदर बनाना है

  • मुझे यह बहुत पसंद है कि Django हर release में थोड़ा-थोड़ा करके लगातार बेहतर होता जा रहा है।
    खासकर 6.0 version में कई काम की features हैं, इसलिए दिलचस्प लग रहा है।
    यह कहना ग़लत है कि भरोसेमंद technology उबाऊ होती है। विकास ऐसा ही होना चाहिए

    • मैं भी pre-1.0 दिनों से इसका इस्तेमाल कर रहा हूँ और अब भी पसंद करता हूँ।
      अभी मैं Django के जन्मस्थान के क़रीब रहता हूँ।
      और हाँ, मैं कल से नौकरी की तलाश में हूँ, इसलिए अगर आप अनुभवी Django developer ढूँढ़ रहे हैं तो संपर्क करें (oldspiceap@gmail.com)

  • Adam का लिखा code या blog हमेशा पढ़ने लायक होता है।
    आगे tasks framework कैसे विकसित होगा, यह देखने की उत्सुकता है।
    बस थोड़ा अफ़सोस है कि शानदार Django-Q2 का ज़िक्र Celery के साथ किया गया

    • लेखक बोल रहा हूँ। तारीफ़ के लिए धन्यवाद, Celery का ज़िक्र सिर्फ उसकी लोकप्रियता की वजह से किया था ;)
    • Celery परफ़ेक्ट नहीं है, लेकिन सबसे अच्छा विकल्प यही है।
      इसमें bugs काफ़ी हैं, लेकिन user base इतना बड़ा है कि किसी समस्या का पहली बार सामना होना मुश्किल है।
      मैंने Celery + RabbitMQ के साथ रोज़ करोड़ों messages भरोसेमंद तरीके से प्रोसेस किए हैं।
      अब भी यह सबसे पहले विचार करने लायक solution है
    • मैं कई सालों से Celery इस्तेमाल कर रहा हूँ, जानना चाहता हूँ कि दिक्कतें क्या थीं और Django Q2 उन्हें कैसे बेहतर करता है।
      दूसरी stacks में Kafka भी इस्तेमाल करते हैं, लेकिन वह बिल्कुल अलग स्तर के use cases के लिए है
    • जिज्ञासा है कि Celery को ‘भयानक’ क्यों कहा जाता है

  • मैं लगभग 5~6 साल से Django इस्तेमाल कर रहा हूँ, और ‘batteries included’ वाली इसकी ताकत तो साफ़ है, लेकिन कुल मिलाकर यह भारी लगता है

  • Template partial feature अच्छा लग रहा है।
    React के लोकप्रिय होने की एक वजह code reusability भी थी, और Django भी शायद उसी दिशा में बढ़ रहा है

    • React की reusability और composability की असली ताकत templates नहीं, बल्कि यह है कि हर चीज़ function है
    • यह feature खास तौर पर HTMX के साथ बहुत काम का है। HTMX को बहुत सारे partial templates चाहिए होते हैं
    • React सिर्फ साधारण templates नहीं देता, बल्कि state को encapsulate करने वाले components देता है
    • मैंने भी Django 6 टेस्ट करते समय अपने blog में partials इस्तेमाल किए
      उदाहरण यहाँ code में है
    • यह हैरानी की बात है कि Django ने ऐसी feature 2025 में जाकर जोड़ी

  • मैं मुख्य रूप से Odoo इस्तेमाल करता हूँ, लेकिन Django और Celery भी थोड़ा चलाया है।
    Odoo के OCA queue module का बहुत इस्तेमाल करने के नाते,
    मैं हमेशा सोचता रहा हूँ कि Django Postgres के LISTEN/NOTIFY feature का इस्तेमाल क्यों नहीं करता।
    शायद इसलिए कि मैं Django ecosystem से ज़्यादा परिचित नहीं हूँ

  • Template Partials और HTMX, Django संस्करण के Rails View Components + Stimulus जैसे लगते हैं।
    Tasks feature का आधिकारिक support मिलना भी अच्छा है

    • Rails में partial rendering official guide में देखी जा सकती है
    • जिज्ञासा है कि production में Tasks इस्तेमाल करने के लिए क्या django-tasks भी साथ में इस्तेमाल करना होगा

  • मैं Django 1.x के दौर से, जब ORM नहीं था, तब से इसका इस्तेमाल कर रहा हूँ।
    अब जाकर task execution feature जुड़ना सचमुच चौंकाने वाला है।
    यह आलोचना नहीं है, बस एक दिलचस्प evolution है

    • उल्टा, यही इसकी ताज़गी है। Django features को जल्दीबाज़ी में नहीं, सही तरीके से लागू करता है।
      हर feature को पर्याप्त रूप से परखा जाने के बाद ही शामिल किया जाता है, और LTS व API stability पर ध्यान दिया जाता है।
      इसी वजह से नया version आने पर पूरे app को फिर से लिखने की नौबत शायद ही आती है
    • Django में दरअसल version 0.95 से ही ORM शामिल था।
      उस समय यह साधारण था, लेकिन काफ़ी लंबे समय तक raw SQL लिखने की ज़रूरत नहीं पड़ी

  • आगे की चर्चा इस thread में जारी है

  • मैं Django और HTMX साथ में इस्तेमाल करते हुए component-level templates से इतना परेशान हुआ कि
    मैंने खुद Python-आधारित component library Compone बना ली।
    यह सिर्फ Django ही नहीं, सभी Python web frameworks में इस्तेमाल हो सकती है, और काफ़ी ज़्यादा आरामदायक developer experience देती है