needs_context for template filters

[Alexander Schepanovski]

Would be great to do something like:

    import pytz
    from django.conf import settings
    from django import template
    register = template.Library()

    @register.filter
    def localtime(dt, context=None):
        if dt.tzinfo is None:
            dt = pytz.timezone(settings.TIME_ZONE).localize(dt)
        return dt.astimezone(context['timezone'])
    localtime.needs_context = True

[Russell Keith-Magee]

I don't see why needs_autoescape and needs_context have to be mutually exclusive, but otherwise, looks like a good idea.

[Alex Gaynor]

I'm opposed to this, to me a template filter is extraordinarily well defined around taking input, and maybe an argument, and operating on those.

[Yeago]

one nag. can we change this to 'takes_context' to fit with templatetag version.

[Alexander Schepanovski]

The value of autoescape parameter is always equal to context.autoescape, so there is no need in passing both. Still I don't mind updating patch to support this. Or docs to not support.

The name 'needs_context' corresponds to 'needs_autoescape' filter property. So some missfit is unavoidable.

Both are kind of design issues

[Aymeric Augustin]

I'm going to implement a filter similar to your example as part of my work on #2626. We can't add an example that duplicates a core functionality, so we'll have to give another example if my work on #2626 is merged. Do you have other use cases for needs_context?

If there isn't another compelling use case, like Alex, I'd prefer to keep the filters "contextless", for the sake of simplicity.

[Alexander Schepanovski]

Datetime timezoning use-case I solved for myself with a custom model field which transforms
its value to user timezone when gets it from db. I also have form field which adds tz info
to datetimes received from user. This two work pretty well, I haven't need to bother
about timezones since I started using them. If you are interested I can push my solution
to github in a few days.

About other use-cases, there were some. One was about rendering forms to separate templates
with a |render filter, other was about url construction depending on host in request which
was in the context. First one will be probably appropriately done with template tags.
Second looks better as filter for me.

I can be biased, though. I really don't like custom tags not created to extend template logic
(some fancy loop or another control structure) but to add some application specific
rendering, because it means that we get rendering (template) logic in our application code,
which is MVC violation.

[Aymeric Augustin]

I still think filters with arguments or templatetags are the way to go for your examples.

Django ​isn't strongly committed to a MVC model, and in the end, "practicality beats purity".

[Aymeric Augustin]

Florian Apolloner added on IRC that if we give access to the context, we allow users to alter the context in filters, which means the filters can have side effects.

[anonymous]

Side effects? What about "practicality beats purity"? But since I migrated to jinja2 I don't care about this feature anymore, and since nobody cares just dropping it seems okay.

As for the big picture django templates don't feel either practical nor convenient, they feel like chains on your arms.
And custom templatetags make your templates less customizable, inheritable and all. Look at django.contrib.admin templates for example.