GSoC 2026 Pre-Proposal: Add Ergonomic Control over Behaviour of Missing Variables in Templates

Hi everyone! I’m Vidhi Singh (vidhiii1711), a 2nd-year B.Tech AI & ML student. I’m interested in working on the template ergonomics idea for GSoC 2026.

About Me & My Contributions

I’ve been contributing to the Django ecosystem and currently have 6 PRs on djangoproject.com, one of which is merged:

  • :white_check_mark: Merged — #1646: Fixed 405 error when non-superuser tries to delete their own feed from the community blog
  • #2446: Migrating project tooling from black/isort/flake8 to ruff (currently under review)
  • #2341: Investigating and fixing caching of 404 responses
  • #877: Replacing robots.txt blocking with noindex meta tag for untranslated docs
  • #2067: Fixing broken links/images when extra slashes appear in URLs
  • #835: GitHub OAuth login not persisting session on community pages

My contributions are on djangoproject.com rather than django/django core. I want to be upfront about that. However, working on these issues gave me a solid understanding of how Django handles HTTP behaviour, middleware, caching, and project configuration — and I’ve been actively reading django/template/base.py to prepare for this proposal.


The Problem

Django templates silently return an empty string when a variable is missing from the context. This is fine by default, but during development, silent failures hide real bugs. A developer who accidentally omits user_email from a view’s context will never know — the page just renders blank.

Proposed Solution

I see two viable approaches and would love mentor feedback on which direction is preffered:

Approach 1 - New Template Syntax (! and ?)

As suggested in the original issue:

{{ username }} → required , raise VariableDoesNotExist if missing

{{ bio? }} → explicity optional, silient if missing

This requires modifying the laxer/parser in django/template/base.py - specifically the Filterexpressionand Variable.resolve() method.

Approach 2 - Per variable context flag

Extend the existing string_if_invalid TEMPLATES settings to support per variable behaviour.

My personal preference is Approach 1 , as it is the most ergonomic for template authors and alings with the original feature request.But I’m open to guidance from mentors.

Why Me

I know my contributions are on the website repo , not core. But every PR I worked on required me to deeply read Django internals - caching middleware , URL resolvers , HTTP response handling , and auth flows. I’m a fast learner and I’ve already started reading django/template/base.py specifically for this proposal. I’m commited to making meaningful contributions to Django core starting now.

Looking forward to feedback from the community and mentors. Thankyou!

1 Like