If you are talking about people writing 0==False in stdlib I argue that's a bad code. There are times when you don't want to distinguish 0, False, None, or empt

If you are talking about people writing 0==False in stdlib I argue that's a bad code. There are times when you don't want to distinguish 0, False, None, or empty. Unlike JS which has == and ===, Python only offers == I like that. Coding like !=0 is very C like to me, or not taking advantage of Python. In the Python world, it is common and advised to test trutfulness until you have to test the actual value. That is, you can get away with a lot of if object instead of if object.size == 0 or if function() == 0, i think you can do this by implementing your own __eq__ and __nq__ for the object. Imagine someone has multiple values to return depending on the logic branch, the following is arguably ugly and bad, but say it happens: if cond1: return -1 elif cond2: return -2 elif cond3: return -3 Unless there is a good reason to return these ints, if you only care about the semantic (to distinguish which branch in the caller's), just raise your own exception. if cond1: raise cond1Exception elif raise cond2Exception So there are ways to go around and make code more readable. is this a bad coding? Each has its own taste.