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

florentx opened this Issue Oct 19, 2010 · 5 comments


None yet
2 participants

florentx commented Oct 19, 2010

This syntax used to work until 2.5.2:

{{ someobj|string[:16] }}

But it gives a syntax error in 2.5.3 and above.


mitsuhiko commented Oct 19, 2010

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?


mitsuhiko commented Oct 19, 2010

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.


mitsuhiko commented Oct 19, 2010

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.


florentx commented Oct 19, 2010

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


mitsuhiko commented Oct 20, 2010

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