Because that’s a fundamental aspect of Python. When you’re using a language, you should be familiar with the truthiness values. In Python, it’s pretty sane:
[], {}, set(), "", None, False0 and related values are all “falesy”
everything else is truthy
Basically, if you have non-default values, it’s truthy. Why wouldn’t you trust basic features of the language?
Because I have to do the is this falsy to what I’m actually interested conversion in my head.
Say ur deep inside some complicated piece of logic and u are trying to understand. Now u have a bunch of assumptions in your head. You should be trying to eliminate as many if these assumptions with good code as possible eg u test ur fail case and return/continue that so u don’t need to keep that assumption in ur head.
Say I then come along a if not x then you have to figure out what is x what is the truthiness of its type. If I come across an if len(x) == 0 then I automatically know that x is some collection of objects and I’m testing its emptiness.
This always evaluates to True if it’s non-empty. There’s no extra logic.
If you have to keep 12 things in your head, your code is poorly structured/documented. A given function should be simple, making it plainly obvious what it’s intended to do. Use type hints to specify what a variable should be, and use static analysis to catch most deviations. The more you trust your tools, the more assumptions you can safely make.
Because that’s a fundamental aspect of Python. When you’re using a language, you should be familiar with the truthiness values. In Python, it’s pretty sane:
[],{},set(),"",None,False0and related values are all “falesy”Basically, if you have non-default values, it’s truthy. Why wouldn’t you trust basic features of the language?
Because I have to do the is this falsy to what I’m actually interested conversion in my head.
Say ur deep inside some complicated piece of logic and u are trying to understand. Now u have a bunch of assumptions in your head. You should be trying to eliminate as many if these assumptions with good code as possible eg u test ur fail case and return/continue that so u don’t need to keep that assumption in ur head.
Say I then come along a if not x then you have to figure out what is x what is the truthiness of its type. If I come across an if len(x) == 0 then I automatically know that x is some collection of objects and I’m testing its emptiness.
That’s why there’s type hinting, unit tests, and doc strings. I don’t need to guess what the type is intended to be, I can see it.
But that’s an extra step of logic u must hold in ur head while trying to understand 12 other things.
What’s the extra logic?
if x:This always evaluates to
Trueif it’s non-empty. There’s no extra logic.If you have to keep 12 things in your head, your code is poorly structured/documented. A given function should be simple, making it plainly obvious what it’s intended to do. Use type hints to specify what a variable should be, and use static analysis to catch most deviations. The more you trust your tools, the more assumptions you can safely make.