I never understood that argument. If you can be sure the type is a collection (and this you always should) not list is so moch easier to read and understood than the length check.
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.
Compact does not mean easier to understand. They are different tests. The point is, do not make code less readable for speed unless speed matters. I am not going to argue which is more readable in any specific case. That is up to the developer.
I never understood that argument. If you can be sure the type is a collection (and this you always should)
not list
is so moch easier to read and understood than the length check.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
,False
0
and 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
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.
Compact does not mean easier to understand. They are different tests. The point is, do not make code less readable for speed unless speed matters. I am not going to argue which is more readable in any specific case. That is up to the developer.
How many elements in that list? Ah, it’s not list. It’s list, of course, we checked. But it’s not.