On Mon, Jun 9, 2014 at 3:38 PM, Przemek Czerkas <[email protected]> wrote:
> Hi, > > In this ticket https://code.djangoproject.com/ticket/13956 (Indefinite > args for simpletags and inclusion tags) a support for *args and **kwargs > for simple_tag, inclusion_tag and assignment_tag was added. > > I think that one piece is still missing. How about allowing to pass > *args/**kwargs to templatetag arguments: > > {% some_tag [positional_args] [named_args] *args **kwargs %} > > where args is a list, kwargs is a dict? > > With this new syntax, the resolution of variable arguments would had to be > moved to the render() phase, as well as some of the argument checking (e.g. > {% with kwargs %} case for empty kwargs). > > Hi Przemek, I'm not entirely certain I understand what you're proposing here. simple_tag, inclusion_tag and assignment_tag are all utility classes that you use to produce template tags; however, all the "native" template tags have their own implementations - which includes, for the most part, their own parsing infrastructure. Note that I'm not necessarily defending this arrangement -- In the past, this has been the cause of inconsistencies in argument handling between tags. However, it is the status quo, and it needs to be taken into account - if only because The side effect of this arrangement is that any custom template tags out there are relying on the fact that variable resolution *doesn't* happen in the render phase - at least, not in any automated or semi-automated way. So - at a high level API level, what you are suggesting sounds interesting - *args and **kwargs are a powerful mechanism in python, and I can see how they might be useful in the context of template tags as a general feature - but I'm not sure I see how this would manifest in practice. The only two approaches I can see are: 1) a backwards incompatible change at the root level of template tag design, or 2) a manual change to each of Django's internal template tags - which would represent a lot of code churn to satisfy a use case that isn't entirely clear. Are you able to clarify how you would see this change happening in practice? Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJxq84_VzjUmkZdKKB_f0SHMkZVaRHShwsWTW93cq0vuj2tEYQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
