Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect behavior of truncate filter #699

Closed
AMDmi3 opened this issue Apr 3, 2017 · 4 comments
Closed

Incorrect behavior of truncate filter #699

AMDmi3 opened this issue Apr 3, 2017 · 4 comments

Comments

@AMDmi3
Copy link

AMDmi3 commented Apr 3, 2017

Code:

from jinja2 import Template

print(Template('{{ "2016.10.26_cc37528" | truncate(11, True) }}').render())
print(Template('{{ "2016.10.26_cc37528" | truncate(12, True) }}').render())
print(Template('{{ "2016.10.26_cc37528" | truncate(13, True) }}').render())
print(Template('{{ "2016.10.26_cc37528" | truncate(14, True) }}').render())

Expected Behavior

2016.10....
2016.10.2...
2016.10.26...
2016.10.26_...

Actual Behavior

2016.10....
2016.10.2...
2016.10.26_cc37528
2016.10.26_cc37528

Template Code

{{ "2016.10.26_cc37528" | truncate(13, True) }}

Your Environment

  • Python version: 3.6.1
  • Jinja version: 2.9.5
@ThiefMaster ThiefMaster changed the title Incorrent behavior of truncate filter Incorrect behavior of truncate filter Apr 3, 2017
@ThiefMaster
Copy link
Member

Check whether this is caused by the leeway argument. The default value for it changed recently.

https://github.com/pallets/jinja/blob/master/jinja2/filters.py#L467

@AMDmi3
Copy link
Author

AMDmi3 commented Apr 3, 2017

It is. Setting leeway to 0 fixes the issue. I'd say it's POLA violation when using short strings.

@davidism davidism closed this as completed Apr 3, 2017
@macropin
Copy link

macropin commented Jul 6, 2017

Yeah I agree @AMDmi3 . We just hit this issue as well.

The problem is that Jinja has an opinionated implementation which is incompatible with usage as a general purpose templating engine.

@diego-treitos
Copy link

I also found this problem and spend several hours finding the bug. Clearly new options should be backwards compatible and the default should be leeway = 0.
Whoever starts using the new option leeway they will know it exists and will use the value they please. Those who dont know about the new parameter wont need to change their code...

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 13, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants