Bug: floats are arbitrarily rounded (no filters used)

Test case is just rendering a float:

$ python -c 'from jinja2 import Template; print Template("{{num}}").render(num=1441712583.216615)'
1441712583.22

4 last digits are not present and the last digits indicates rounding.

If I delete 3 last integer digits I get 5 rounded fraction digits (instead of full 6):

python -c 'from jinja2 import Template; print Template("{{num}}").render(num=1441712.216615)' 
1441712.21662

Unless I’m overlooking something stupid, it’s a critical bug. I tested it on Jinja2 2.7.3 and 2.8.0 and CPython 2.7.6 and PyPy 2.6.1.

[aartur]

Jinja isn’t only used to directly produce “customer facing representations”. Even when it’s used to produce HTML, there are major usages (data-* attributes, elements, Javascript fragments) for which you want a higher precision for floats. it’s also advertised as working good not only for HTML, and indeed it’s widely used for things like source code or configs (Salt and Ansible).

For me the behavior of str(float_val) (using up to exactly 17 digits of representation) is weird and I don’t see reasons, other than being easy to implement in CPython, that it was chosen.

[mitsuhiko]

This won’t change because it would require special casing floats. I’m happy to accept filters to improve float rendering in general for specific cases.