That doesn’t solve the problem of defining common Python iterables, though. But I understand that this is added comlexity to the DTL and you need a good reason for that. So here is a practical use-case, very common that have met several times when working on Django projects.
Let’s say I have {% my_custom_tag %} that spits out whatever HTML. Now, as I use Stimulus, I want to be able to pass data-* attributes to that custom tag. Then I can’t use @register.simple_tag and pass {% my_custom_tag data-controller="my-controller" %} because this raises TemplateSyntaxError: Could not parse the remainder: '-controller="my-controller"' from 'data-controller="my-controller"'. If I want to be able to pass dashed HTML attributes as tag kwarg, I will have to go as far as writing a custom node that parses "my-controller" as "data-controller" like I did on dj-importmap.
Now, you could answer that I can define this in get_context. And, sure I can. But that breaks both separation of concerns and locality. It’s not data, it’s not logic, it’s HTML. It doesn’t belong in the view, it belongs in the template, like all the other HTML attributes that define the behavior of my controller.
I think that now the Django community has adopted JS frameworks heavily relying on HTML atttributes, like Stimulus or htmx as a standard, it could be a goo idea to support defining standard Python iterables in template variables.
Again: I understand the will to not add uneccessary comlexity to the language, which is why I propose to limit these to only {% with %} and {% set %}.