#34521: Use __slots__ for template Node classes
-------------------------------------+-------------------------------------
Reporter: Adam Johnson | Owner: Adam
Type: | Johnson
Cleanup/optimization | Status: assigned
Component: Template system | Version: dev
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Carlton Gibson):
I'd like to argue for wontfixing this, at least for a couple of release
cycles...
Copying my
[https://github.com/django/django/pull/16805#pullrequestreview-1430606122
comment from the PR]:
> Can I ask that we pause on this please?
>
> I'm currently investigating possible implementations for _Template
Fragments_ (or _Partials_), as per the [HTMX essay on that
theme](https://htmx.org/essays/template-fragments/).
>
> Whilst custom template tags have long been able to write to the
`context`, this route isn't available for (an as yet in-development)
_partial nodes_ that are not rendered, for example because they're
declared outside a `block`, or are rendered **after** they're required for
output, because of varying rendering order due to inheritance, say.
>
> In order to work around this, and in order to allow partials to
resolvable from a specific template, I'm currently assigning a mapping to
the template Origin to serve as a lookup store.
>
> This isn't particularly _nice™_, but it functions, and allows work on
the prototype to continue.
>
> My current implementation works on Django 4/2, but is broken by this PR.
>
> * Can no longer create weak references to template objects. (This could
be worked around but...)
> * Can no longer assign a mapping to any object that's available at both
parsing and rendering time, and so there's no (immediately) clear way to
pass partial references out from the parser.
> * A module global might work here, but it's difficult to maintain the
correct per-template mapping, and (more) even using weakref for the storer
making sure other references are dropped has proved non-trivial in my
experiments thus far.
>
> Beyond seriously putting in doubt my current work, I think forcing slots
here makes experimenting with the DTL much harder, and I don't think
that's paid for by the speed increase on offer. We're only now beginning
to come back to _What's possible with templates?_, after a long period of
JSON APIs being primary. I'd like to ask that we don't handicap that by
overly restricting what's easy to do with template objects.
>
> I also note that in researching this project, there is a long history of
people trying all sorts of customisations (and I was only looking at
output capture). Given that this PR breaks my WIP, I'd be surprised if it
didn't lead to breakages more widely.
>
> I appreciate that it's not part of the official contract for template
object **not** to use slots, but I think it's a pretty major change.
tl;dr: With fresh attention, there are plenty of gains to be made to the
DTL. Making everything use slots make experimenting with that harder.
Thanks.
--
Ticket URL: <https://code.djangoproject.com/ticket/34521#comment:7>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/0107018829c4b22d-9d2e7a2b-589a-415e-90af-874690431ede-000000%40eu-central-1.amazonses.com.
