Feedback Request: GSoC 2026 - Template Engine "Undefined" Types Architecture (Issue #5)

Mentorship Google Season of Code
1

Hi everyone,

Following up on my introduction post! I just finished submitting my 3rd patch (fixing the admin UI layout flicker in #35798) and am now evaluating the “Ergonomic control over missing template variables” project for GSoC 2026.

I read through the forum discussion from last year, and I am particularly interested in Adam Johnson’s and boxed’s points regarding the architectural risks of introducing ! syntax. Specifically, how a hard syntax change forces boilerplate and risks breaking implicit existence checks like {% if missing_var %}.

Instead of modifying the lexer for !/? syntax, I would like to base my GSoC proposal around introducing Jinja2-style Undefined types to the Django Template Engine.

My initial architectural thought process:

  1. The Core Change: When a variable fails resolution, return an Undefined object instead of an empty string.

  2. Graceful Degradation: By utilizing Python’s magic methods on the Undefined class (e.g., allowing __bool__() to evaluate to False while making __str__() raise an exception), we can catch rendering bugs {{ missing }} without breaking standard control flow {% if missing %}.

  3. Environment Strategy: Allow developers to configure the active Undefined class in OPTIONS (e.g., StrictUndefined for local dev, LoggingUndefined or SilentUndefined for production/admin compatibility).

Before I draft my formal 350 hour timeline, I would love the feedback on this direction. Does migrating toward a class-based “Undefined” evaluation strategy align better with Django’s long-term template goals than introducing explicit ! syntax markers?

Thanks,

Abhishek