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

Consider allowing boolean tests of arbitrary values to fail #211

Open
brandjon opened this issue Feb 10, 2022 · 4 comments
Open

Consider allowing boolean tests of arbitrary values to fail #211

brandjon opened this issue Feb 10, 2022 · 4 comments

Comments

@brandjon
Copy link
Member

The spec requires that

any value may be converted to [...] a Boolean truth value using the expression bool(x).

This FR would consider relaxing this to allow truth-checking to fail for certain types, so e.g. if some_application_defined_type: could be an error.

This would enable banning (via a dynamic error) certain patterns that are error-prone, such as Bazel's select, where a boolean could be inadvertently conflated with an object wrapping a computation yielding a boolean. See bazelbuild/bazel#14506.

Downsides: This would effectively prohibit programmatically taking the truthiness of arbitrary values, including where this is done implicitly (without calling bool()), and break existing code that does this. A more minor detail is that it would require implementaitons (particularly the Java interpreter) to propagate an exception where one is not declared today.

Alternatives: Rely on linting, style guides, and documentation to mitigate the damage caused by that kind of confusion.

Personally I'm hesitant to restrict truth-checking in this way.

@laurentlb
Copy link
Contributor

Note that it would also break some patterns, like x or default_value

@brandjon
Copy link
Member Author

See update in aforementioned bug. We want to do this, at least for implicit bool conversion.

@adonovan
Copy link
Contributor

Personally I'm hesitant to restrict truth-checking in this way.

Me too. Truthiness has long been a part of Python style, and revoking it would be an enormously incompatible change.

@brandjon
Copy link
Member Author

brandjon commented Dec 4, 2024

The counterargument is that almost every usage of a select() as a bool is a bug, including usages that arise from passing them to libraries that assume the given value is truth-able. If the library owner is not expected to handle such a value then it shouldn't hurt readability. (That "if" is perhaps suspect though.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants