Hi @clokep — thanks for posting.
I very much wanted to be able to leverage render-block, but couldn’t see a clear way to getting the partial (or block?) reuse that I needed. (The block lookup is also at-best linear complexity, whereas I wanted something constant time.)
I’d be very grateful for your input here: you’ll have learnt lessons that I won’t have spotted yet! The goal isn’t really a new library, but rather a change to the DTL itself so that neither are needed.
@apollo13 Thanks for your points…
I actually prefer the partials approach to blocks. I don’t know about your templates but, more times than not blocks in my templates are empty. Sometimes I put default content, and use block super, but more likely not. Adding a block around a bit to reuse with render-block works, but it’s a little artificial. For me, having the partials defined at the top makes the template structure easier to read, navigate, and edit, when I’m adjusting (say) just the partial. — but this whole paragraph is one we could back and forth on without resolve.
The partials approach though gives a very clean to-and-from using includes. Say I’m using includes now, I can merely move them to the top of my main template, and then adjust the {% include ... %} to {% partial ... %} and I’m done. The rest of my template is unaffected. Later, when Locality of Behaviour is no longer dominant, I can just do the reverse. Again, very little disruption to the rest of what I’m doing. It’s this clean growth path that I’d highlight when thinking about fit with the DTL.
I’m using partials already in complex templates, in loops etc. I’ve not hit any issues yet. A partial is ≈ a NodeList, which gets rendered with the context in play. There are some wiggles for when rendered separately, to account for binding to the request context, but that’s handled. We can add more tests happily.
Ref Jinja, I see this as entirely internal to the DTL… I’m not sure what’s relevant there: Django just provides the backend interface no? 
(If adding features to Jinja is in scope for Django, that’s something that I’d prefer addressed separately, not least by someone who actually knows Jinja 
)
This ties into my point about needing to adjust the parsing API… — I wanted to use the ability to just set values in the context originally, but it turns out that doesn’t work, due to A) non-rendered nodes, declared outside a block, and B) ordering of rendering depending on template extensions — it’s just too fragile — so there needs to be someway (an official™ map to stash values in would be enough) to attach additional data to the template object from the parser. If we had that, I’d be able to clean up the initial implementation (which is pretty lightweight as it is) and we’d open up a pathway for more flexibility here. (My first pass would be to look at making this small change, before we settle the main topic here.)
Hope all that makes sense. Thanks both!
C.