Is it? Why introduce an additional conversion from not list means empty list that u have to hold in your head. I want to check length I check length I would argue is easyer to comprehend.
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.
Is it? Why introduce an additional conversion from not list means empty list that u have to hold in your head. I want to check length I check length I would argue is easyer to comprehend.
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.