someobj|string[:16] no longer works about jinja HOT 6 CLOSED

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?

from jinja.

Generally that problem arises because foo.bar 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.

from jinja.

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.

from jinja.

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

from jinja.

Another usecase that came up is this:

{%- for c in current_category.fullpath|list[:-1] -%}

from jinja.

Closing this off since it appears as though the recommended way of doing this is to wrap the expression in () before slicing it.

I can confirm that this issue still exists on 2.10.x though.

from jinja.