Python Performance: Why 'if not list' is 2x Faster Than Using len() (blog.codingconfessions.com)

submitted 5 days ago by jnovinger@programming.dev to c/python@programming.dev

52 comments fedilink hide all child comments

you are viewing a single comment's thread
view the rest of the comments

[-] sebsch@discuss.tchncs.de 5 points 5 days ago

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.

[-] Nalivai@lemmy.world 4 points 5 days ago* (last edited 5 days ago)

How many elements in that list? Ah, it's not list. It's list, of course, we checked. But it's not.

[-] furrowsofar@beehaw.org 3 points 4 days ago* (last edited 4 days ago)

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.

[-] muntedcrocodile@lemm.ee 2 points 4 days ago

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.

[-] sugar_in_your_tea@sh.itjust.works 2 points 4 days ago

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"
everything else is truthy

Basically, if you have non-default values, it's truthy. Why wouldn't you trust basic features of the language?

[-] muntedcrocodile@lemm.ee 1 points 4 days ago

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.

[-] sugar_in_your_tea@sh.itjust.works 0 points 4 days ago

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.

[-] muntedcrocodile@lemm.ee 1 points 4 days ago

But that's an extra step of logic u must hold in ur head while trying to understand 12 other things.

[-] sugar_in_your_tea@sh.itjust.works 1 points 3 days ago

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.