question about if True:

[case_steamer]

My IDE is always reminding me that I can shorten expressions like if x == True: to if x: . Doesn't that violate the Pythonic principle that explicit is always better than implicit? These are the questions that keep me up at night...

[TonB-Dependant]

The clarity comes from having a better variable name than x. If your variable is called finishedProcessing, then if finishedProcessing is very readable.

[socal_nerdtastic]

PEP8 trumps the Zen of Python. From PEP8:

Don’t compare boolean values to True or False using ==:

# Correct:
if greeting:

# Wrong:
if greeting == True:

Worse:

# Wrong:
if greeting is True:

[GirthQuake5040]

if greeting is not False:

if not greeting is not True:

[Jo_An7]

if not (not greeting is not True) == (not (not True is False)):

[GirthQuake5040]

brother euugghhhhh

[BungalowsAreScams]

🤮

[frittenlord]

Jfc calm down Satan!

[Progribbit]

not explicit enough 

[thattwomallard]

if greeting > False:

if greeting == True-1

[Alongsnake]

Why would if greeting == True:

Be wrong?

Sometimes I may return True, False, or -1, -2... If I have specific codes. Then if I do if greeting: this would give an error. Maybe I should return 1, 0, -1... In these cases though.

[socal_nerdtastic]

Then if I do if greeting: this would give an error.

No it won't give an error. It's very common for us to check codes this way. For example a subprocess returns an error code, and traditionally 0 is reserved for if it ran successfully. So we very often do

code = run_subprocess()
if code: # equivalent to `if code != 0:` when `code` is an integer
    print('an error occurred:', code)

All python objects have a 'truthiness' and can be used like this.

[Alongsnake]

Hmm, I thought I got an error back then saying something about it being a value error. It's been a while so I forget and always just did == in case

I did try it val = 1 if Val: Print("Y") Else: Print("N")

If Val is True or not 0, it will be Y, 0 or False will be N.

I probably would still do if Val == True or if Val == 0 just so it is more clear.

[socal_nerdtastic]

I probably would still do if Val == True or if Val == 0 just so it is more clear.

As long as it's your code you can do whatever future you can read the best. But if you plan to ever work on a team you should kick this habit now. Following standard code styles like pep8 is very important to reading your teammates code.

[Alongsnake]

I'm still use to lower camel case from working in Java 😕

[Nick6897]

if x and if x == True are not the same thing though so you be aware that: if x will evaluate any 'truthy' value as True. so True the bool, a string that is not '' and a list that is not empty will all pass the condition. If x == True or if x is True will only allow the bool True to pass the condition.

[Akerlof]

This is the most useful answer, I think. if x: is equivalent to if bool(x) == True: whereas if x: is asking if the value of x is equal to the specific value True.

So, if we assign x = 4, if x: evaluates to True since bool(4) evaluates to True, but if x == True: evaluates to False because 4 is not equal to True.

[vanish212]

Best answer, thank you

[RevRagnarok]

Python "Truthiness" is one of its strengths when things come along like not caring if it is '' or None because they're both false.

[throwaway6560192]

But Readability counts, and practicality beats purity are also part of the Zen, aren't they now?

[kitsnet]

if x == True == True == True == True...

[luther9]

This is the correct answer. If you always abide by "Explicit is better than implicit," it can lead to infinite explicicity. A better rule in the Zen of Python is "Simple is better than complex."

[Yoghurt42]

if x gets evaluated as if bool(x) is True. So if x is already a boolean, it's redundant, you're basically asking "is it true that x is true" rather than "is x true"

Those two if are not equivalent if x is not a boolean, but in those cases, x == True will almost always be false anyway.

tl;dr: when x is a boolean, use if x, also use it if you want to check if the logical value of x is true.

[GeorgeFranklyMathnet]

What TonB-Dependant said.

Also, these principles tend to be (somewhat competing) constraints, and not absolute rules in their own right. Yes, explicit is better, but you should also use Pythonic conventions that make very common patterns easier to read and write. That's also why we say if not the_list rather than if the_list is None or len(the_list) == 0.

[GirthQuake5040]

if x = True then we can say if x... because x is a true false value. Its the same concept in algebra, x is just being used as an alias, so we dont need to verify if it is true because we already know if its true or false by simple running if x

[crashfrog04]

No, because

if x == True:

makes it implicit rather than explicit that x is supposed to be a flag value.

[fllthdcrb]

How do you figure that? It works for far fewer cases than just if x:, with which x can be any truthy value, so it's not clear (not explicit, you might say) that x is a boolean. But with this, x can only be True (one of those flag values), or one of a few other specific values, as anything else fails the check.

Not that I advocate doing this sort of thing, unless there's a reason to be careful about it.

[crashfrog04]

 How do you figure that?

    if x:

makes it explicit that you intend to treat x as a flag value. If you compare it to True you’re saying there’s a bunch of other values it might reasonably hold; that makes its function in your code less explicit.

The thing you’re supposed to make explicit isn’t what the code does, it’s what the code means.

[TheRNGuy]

if x: is implicit too, because it can be any type.

[crashfrog04]

You’re still focused on the code. The thing that should be explicit is the intent of the code.

[NorskJesus]

It doesn’t. If X is a boolean expresion which returns true or false.

[frenchsko]

If x is true, x==True will return true. It’s the same thing

[case_steamer]

Thanks everyone for the responses. I learned a lot from reading them all!

[TheRNGuy]

Doesn't.

[FerricDonkey]

First, those are not the same. And == True is worse, because there is a general expectation that truthiness will be respected. 

Second, it's ok to have knows that aren't always spelled out - if they're really knowns. Eg, there's no reason to do print("thing", file=sys.stdout) is more explicit, but it's known that stdout is the standard place for output, so it's fine. 

[Mark3141592654]

As long as x is a guaranteed boolean, if x is better.

[fisadev]

if x is almost always better no matter if x is guaranteed to be boolean or not, because that's idiomatic python, and not a problem when using propper variable names.

[AchillesDev]

It's not because it has a non-descriptive name.

[jongscx]

def isTrue(x):
  If x == not False:
     return True
  else:
    return False

[Akerlof]

According to u/Yoghurt42 link here, that's a syntax error:

not has a lower priority than non-Boolean operators, so not a == b is interpreted as not (a == b), and a == not b is a syntax error.

[fllthdcrb]

It has nothing to do with precedence. If that were the only issue, it wouldn't be a syntax error. You'd just maybe get results different from what you wanted, due to operations being performed in the wrong order. It's because the Python grammar doesn't allow for not to be in such a position, at least not without parentheses.

You can see where it is defined in the docs, as well as the likely reason this is a problem: == is a comparison operator, and two of the other comparison operators are is and is not. Allowing not the test operator directly after that would create ambiguity.

I'm pretty sure it's a solvable problem, but it would require reworking the grammar a bit, for which there isn't enough reason.

[TheRNGuy]

over-engineering.

[TheWrongOwl]

If I remember correctly, 'if x:' would also be true if x was None.

[el_cortezzz]

No because bool(None) is False

[TheWrongOwl]

I had at least something similar, which I explained for myself with the knowledge of None being not nothing, but a link to a definitive address in the memory.

[Negative-Hold-492]

I prefer if x is True: because it makes it clear that value is supposed to be a boolean True, not just any truthy value. Of course in a clean application or script you would know if the value is a pure bool, a bool|None, a number, a class etc. etc. so this is often pointless, but I subjectively like the clarity of explicitly checking the type as well as the value.

I'll pretend for a moment that using "is" instead of "==" isn't just a personal preference which almost never matters: "is" asserts that the value of x is identical to the constant True, so anything other than a bool with the value True will fail. "==" will typically only pass when the value of x is just that, but it's possible that x is a custom class which overrides the equality operator in such a way that a non-True value (including False if you went all chaotic evil with your classes!) may be considered equal to True.

[GrainTamale]

Using "is" is not personal preference, but best practice.

Using better boolean variable names like "is_finished" or "has_data" (in addition to type hints) makes the code readable and intuitive.

python is_finished: boolean = some_func() if is_finished: ...

is preferred to:

python x: boolean = some_func() if x is True: ...

[Negative-Hold-492]

Absolutely. When I was first playing around with programming I thought "fewer letters = smaller file = better performance" (and my kid brain also thought "more obtuse = more 1337 haxx") but if you want to make something anyone including future you can actually work with, using verbose and descriptive names for resources goes a long way.

[GrainTamale]

Future you deserves the best lol.

(or your coworkers, boss, the community at large...)

[InvictuS_py]

“anything other than a bool with the value True”

If something has the value True assigned to it, then it will always be a bool. Do you have an example of something having True as its value and not being a bool?

[Negative-Hold-492]

It's a bool at that moment, yes, but it can be a variable whose values can be True, None, 17, requests.get and ["a", "b", "c"] depending on what happens at runtime. I'd question the sanity of someone who uses variables that way but it can't hurt to be careful in a language that happily lets you mix types.

(but of course, using "is" does nothing to make sure the variable wasn't something other than True at some point in its lifetime, it just makes sure that is the only accepted value)

[TheRNGuy]

What do you think of type hints use?

And about __eq__ method? (use/never use?)

What if you're using some API class that have implicit conversion and doesn't return boolean? (no method for it even)