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

bool to string filter does not work #882

Closed
pkrasimirov opened this issue Aug 6, 2018 · 14 comments
Closed

bool to string filter does not work #882

pkrasimirov opened this issue Aug 6, 2018 · 14 comments

Comments

@pkrasimirov
Copy link

Expected Behavior

Filtering bool to string should give True or False respective of the value.

Actual Behavior

Filtering bool to string always gives False.

Template Code

Paste the template code (ideally a minimal example) that causes the issue

'{{6 > 0}}' ==> True
'{{6 > 0|string}}' ==> False
'{{6 > 0|bool}}' ==> True
'{{6 > 0|bool|string}}' ==> False

Your Environment

  • Python version: 2.7
  • Jinja version: Don't know the Jinja version, Ansible is 2.5.4
@ThiefMaster
Copy link
Member

ThiefMaster commented Aug 6, 2018

try (6>0)|... or even better, a literal boolean such as true|... or false|...

@pkrasimirov
Copy link
Author

Yes, (6>0)|... works. Why is this bug report closed?

@ThiefMaster
Copy link
Member

ThiefMaster commented Aug 6, 2018

Because it's not a bug, but simply operator precedence. Without parentheses your code was probably running as 6 > (0|string) which obviously makes no sense, but in other operations such as 6 > '5'|int it makes lots of sense, so this is neither a bug nor unintended behavior.

@pkrasimirov
Copy link
Author

Coming from the Unix/Linux world where | denotes a pipeline delimiter this is unexpected.

I think it should be 6 > ('5'|int) insteads when needing such casts.

@ThiefMaster
Copy link
Member

I disagree, and this would also be a massively breaking change.

@pkrasimirov
Copy link
Author

Can we have a warning at least?

@pkrasimirov
Copy link
Author

Real-world use-case for this is Ansible templating Java boolean properties:
isEnabled={{ some_var | length > 0 | string | lower }}
because I want isEnabled=true/false instead of isEnabled=True/False.

@jackwilsdon
Copy link
Contributor

That would be more readable as isEnabled={{ ((some_var | length) > 0) | string | lower }} (to me at least), which I believe would work as expected.

@ThiefMaster
Copy link
Member

{{ (some_var|length > 0) | string | lower }}

More readable, and much clearer what it does

@pkrasimirov
Copy link
Author

Well, I see we read it differently and Jinja currently reads it as you do. But the worst part of the above non-working example is it always silently gives False.

I know Python is happy with that but do you think is it a good idea to issue a warning when using > between int and string in Jinja templates?

@pkrasimirov
Copy link
Author

Also please share your opinion on an |is_empty filter to use instead of |lenght > 0.

@pkrasimirov
Copy link
Author

Anyway, thank you for your quick responses. Have a nice week.

@ThiefMaster
Copy link
Member

Ansible can add this. Just like they did with |bool which is not part of Jinja itself either.

I know Python is happy with that but do you think is it a good idea to issue a warning when using > between int and string in Jinja templates?

Haven't tested it, but probably it does fail in Python 3 where such comparisons fail loudly instead of silently succeeding with a somewhat useless result. Jinja does not do type checks, so it just passes the two operands to Python (didn't check the code, probably it calls operator.gt(a, b) for it)

@pkrasimirov
Copy link
Author

Nice to know, thank you.

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

3 participants