== and is are not entirely equivalent in Python, with both differences in evaluation speed and outcome. Even though I think it's fine to use the equality operator here, I think the proper way to do it would be to add assert_is and/or assert_is_none functions (e.g. unittest also has these: https://docs.python.org/3/library/unittest.html#assert-methods)

I think I'm getting confused here :)

We need to converge on some code style here otherwise we cause only confusion #23127 (comment)

cc @MarcoFalke

These functions are generally (e.g. https://docs.python.org/3/library/unittest.html#unittest.TestCase.assertTrue) used to do a boolean comparison, which makes it functionally different than using assert_equal(expr, True)

It wouldn't make a functional difference in the places where it's currently used (where a simple assert would suffice), but otherwise, this is how I think it should be done:

with this suggestion, you will create an error a runtime and no static checker can find it. We can use the only good thing of python language to write something like that

def assert_true(thing: bool, err_msg=None):
    if thing is not True:

In this way, the editor is able to catch the type mismatch! the cast of a type at runtime should be an antipattern in all modern language

The only way bool(thing) throws an error is if thing is of a custom type that explicitly overrides __bool__() to return something other than True or False, which is... really bad code. I don't think we need to handle that, and we can easily observe if it happens from the stacktrace.

Even though I'm a fan of type hints, I don't think they change anything here - afaik we don't use tooling like mypy that would enforce them? It also wouldn't do the boolean comparison which was kinda my point: you don't want assert_true() to just verify if something is equal to True/False (assert_equal can do that), it's helpful if you need to check if the boolean of an object would evaluate to True/False. For example:

result = some_func()  # some_func returns 0 if it failed, an int between 1-5 if successful
assert_equal(result, True) # this would not work, because e.g. `3 == True` would fail
assert_equal(bool(result), True)  # this would work, but you can't inspect `result` when the assertion fails
assert_true(result)  # this would work if `assert_true` evaluates bool(result), because `bool(3) is True` would pass

if(result):
    do_something_else()

But to reiterate, I'm advocating against implementing assert_true() at this moment, so I'll leave it here

You are right! The thing is worst than the exception because happens something like that

➜  ~ python3
Python 3.8.10 (default, Jun 22 2022, 20:18:18) 
[GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> bool(12)
True
>>> bool("Alibaba")
True
>>> 

This can not hide bugs?

I think to make all happy here is to use the assert_equal everywhere it is possible and move on.

This is code that I wrote one year ago, so I do not remember why I insert assert_true, but if I was not drunk I think because somewhere there is some comparison with custom error messages that check a boolean condition.

Anyway, I think if you agree we can move all on assert_equal and move on.

you don't want assert_true() to just verify if something is equal to True/False

To sustain your thesis, I'm not able to see any real use case other than toy example of how this can be used

How is that worse? You just need to use the right tool for the job. If you need to compare equality, you use assert_equal. If you need to do a boolean comparison, you use assert_true. If you don't know your input type, you should probably validate/convert that first. If you don't need to do a boolean comparison (i.e. if you wouldn't want "Alibaba" to evaluate to True), then you just don't use the boolean assertion?

The point of these functions is to check how something would be evaluated to a boolean, as in the example I gave where the program flow is based on if(result). We don't seem to have that need in our test suite atm, so hence we shouldn't have assert_true.

Mh! I do not argue this on the PR because it is the wrong place but I disagree with this statement

How is that worse? You just need to use the right tool for the job.

Of course, bug is a bug, and it is there because there is a mistake in the code, so if a comparison between bool, I want to compare boolean value and not a string that always evaluates to true except for empty.

Is worse because if we were able to catch this bug easily we were still coding in C without struggling with rust compiler, if you do this case you should define some rules like: bool("False") -> False or True?

Imagine to have assert_true(json['foo']) and make an API change that move the type of a filed from string to int

you fall in case of

Python 3.8.10 (default, Jun 22 2022, 20:18:18) 
[GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> bool(0)
False
>>> bool("0")
True
>>> bool(0.0)
False
>>> bool("0.0")
True

It is not the right tool anyway at least without a good reason to allow this, and I do not see any till now

A better example can be

take the from our assert_true(hash_str is None) with assert_true(hash_str)

➜  ~ python3
Python 3.8.10 (default, Jun 22 2022, 20:18:18) 
[GCC 9.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> bool(None)
False
>>> bool("")
False

This can be a bug not catch by the CI, and if it is an API change you can break the client that use a strongly typed language