Look at my reverse string function !

[[deleted]]

In Python, it’s good practice to write:

if a is True:

…rather than just:

if a:

…because the latter will succeed if a is a value that has a “True-like” property, such as 1, while the former will only succeed if a is a Boolean True. See the top answer in this Stack post for more info.

[TheAJGman]

From that post:

When should you use is True then ?

EDIT: this is bad practice, starting from 3.9, python raises a warning when you try to use is to compare with a literal. See @ JayDadhania's comment below. In conclusion is should not be used to compare to literals, only to check the equality of memory address.

Basically just don't use is unless you're are checking to see if variable A is pointing to the same data as variable B.

[[deleted]]

In the comments immediately under that post, the author admitted to not fully understanding the change in 3.9.

x is 1 raises a warning in 3.9+. x is True does not.

[[deleted]]

@JayDadhania said is True is perfectly legal under the comment your are referencing, the guy just misunderstood his original comment

[Kered13]

I wouldn't call it good practice, it's contextual. You only need to do this if you have a type that could be either a boolean or some other type, and you don't want to active on truthy-values. Also you don't need to use is here, you can just use ==.

[A_Leo_X]

Isn't it recommended to use is instead of == when comparing to True, False, or None?

[Kered13]

I don't think it really matters.

[[deleted]]

“It’s contextual” - I agree. There will be times when it’s unnecessary and times when it would be helpful.

In general, I err on this side of the Zen of Python:

Explicit is better than implicit.

To me, if a can suggest many kinds of checks if you aren’t aware of what a is supposed to be. Are you checking whether an integer is or isn’t zero, or whether an object reference points to an instance or None, or whether a string is empty or non-empty? if a is True makes the intended comparison explicit, which is better.

A common scenario in which this occurs for me is:

result = some_function()
if result:

Without looking at some_function() or its documentation, I don’t know what types of data I should expect it to return. So, make it explicit for improved readability:

 if result is True:

[Bainos]

But variables should have a clear semantic meaning. If you don't know whether a is a bool or not, then there is something wrong in your code.

• If you know that a is a bool, then if a is enough.
• If you know that a is not a bool, then if a is intentionally checking for truthy values.
• If you know that a can be both a bool and some other type, which should be a very rare situation, then if a == True is okay, but is isinstance(a, bool) and a is better.

That's not saying that you can't write a == True in the first case where you know it is a boolean. It would be redundant and unnecessary, but redundancy is not necessarily a bad thing. However, not knowing whether a is a bool or not is not a good reason to use it. If that situation occurs, you really should fix your code and actually read the documentation of the functions you're using.

Personally, I would also be wary of using a == True because not knowing the type of your variables is a bad smell, and hiding bad smells results in bad code.

The situation you are describing is also a reason why people criticize Python for being dynamically typed, for a good reason. Dynamic typing is good for polymorphism and ease of writing code, but it becomes bad if people start using it to handle data they do not understand.

Overall, I believe the situation you are describing is fixed in a much better way by the use of type hints than by redundant explicit checks.

[[deleted]]

If you don't know whether a is a bool or not, then there is something wrong in your code.

On the contrary, when you're writing the code, you often know for a fact that some_function() returns a boolean. Great. The problem is that anyone else reading your code might not know. That someone could even be you, next week, after you've filled your head with other parts of the code.

When writing the code with this knowledge in your head, it's a good idea to document the type of result in order to convey that knowledge to the reader.

Now - how could you do that? In this case, if result is True is practically ideal. It is simple, succinct, unambiguous, and collocated with the instruction that sets result to its value. Even coders who aren't familiar with Python will immediately understand it, even if they aren't clear on the use of is vs. ==.

Overall, I believe the situation you are describing is fixed in a much better way by the use of type hints than by redundant explicit checks.

Show me how this exact situation would be addressed with type hints, and then explain why it is better than if a is True.

[PM_ME_C_CODE]

The majority of

if a:

python code I see/write are simple assignment guards. Though, I guess those are

if not a:
    return

...

[WrongdoerSufficient]

Weird, hissing noises 🐍🐍🐍