Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP


someobj|string[:16] no longer works #2

florentx opened this Issue · 5 comments

2 participants


This syntax used to work until 2.5.2:

{{ someobj|string[:16] }}

But it gives a syntax error in 2.5.3 and above.


This was never supposed to work though. The correct syntax for this case would always have been this:

{{ (someobj|string)[:16] }}

Now I might finally properly support that in a new patch release, but there is a reason why subscriptions are not supposed on filters: they are confusing. Because filter names can contain dots, this for instance would not be valid at all:

{{ soneobj|string.upper() }}

This will give an exception that there is no filter named upper. Again, I am fine changing so that foo|filter[foo] works, but I think it's not a bad idea to change this behavior. I agree that this should not have been done on a patchlevel release, but this was caused by a bugfix for another syntax problem with priorities.

The core issue is that filters have completely different binding rules and are designed to support filter chaining. However there is actually currently one expression that can be applied after filters: calls. This is also was not a very clever design principle, but it was tested and supported earlier on.

I suppose a possible fix would be fixing this in 2.5.6 and then introducing a deprecation warning in 2.6 for both function calls after filters that are not using parentheses and {{ foo|string[42] }} instead of {{ (foo|string)[42] }}.

Would this be a possible upgrade path?


Generally that problem arises because is supposed to be mostly equivalent to foo['bar'] and that cannot be achieved for filters due to their ability to have dotted names. And I don't want to introduce context-sensitive exceptions.


Actually, one might solve that ambiguity also by using explicit parentheses on the filter if I would make it possible to use [...] after filters:

{{ foo|string().upper() }}

Not sure how nice this looks on the eyes though. What would be the use case for subscribing after the filter in your case? If it's common enough I see no reason in deprecating that functionality in general.


I'm ok with using the syntax (foo|string)[:16]
The deprecation path through 2.5.6 / 2.6 may be safer probably.


Another usecase that came up is this:

{%- for c in current_category.fullpath|list[:-1] -%}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.