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

type safe python is a myth

Sure, but type hints provide a ton of value in documenting for your users what the code expects. I use type hints everywhere, and it's fantastic! Yes, there's no guarantee that the types are correct, but with static analysis and the assumption that your users want their code to work correctly, there's a very high chance that the types are correct.

That said, I lie about types all the time. For example, if my function accepts a class instance as an argument, the intention is that the code accept any class that implements the same methods as the one I've defined in the parameter list, and you don't necessarily have to pass an instance of that class in (or one of its sub-classes). But I feel like putting something reasonable in there makes a lot more sense than nothing, and I can clarify in the docstring that I really just need something that looks like that object. One of these days I'll get around to switching that to Protocol classes to reduce type errors.

That said, I don't type hint everything. A lot of private methods and private functions don't have types, because they're usually short and aren't used outside the class/file anyway, so what's the point?

isn't the expected behaviour exactly identical on any object that has len defined:

"By default, an object is considered true unless its class defines either a bool() method that returns False or a len() method that returns zero, when called with the object."

ps: well your objection is I guess that we cant know in advance if that said object has len defined such as being a collection so this question does not really apply to your post I guess.

My ad blocker has blocked all pictures on this article, so I can't say. 😄

It's all about trade-offs. Here are a few reasons why one might care about performance in their Python code:

1. Performance is often more tied to the code than to the interpreter - an O(n³) algorithm in blazing fast C won't necessarily perform any better than an O(nlogn) algorithm in Python.
2. Just because this particular Python code isn't particularly performance constrained doesn't mean you're okay with it taking twice as long.
3. Rewriting a large code base can be very expensive and error-prone. Converting small, very performance-sensitive parts of the code to a compiled language while keeping the bulk of the business logic in Python is often a much better value proposition.

These are also performance benefits one can get essentially for free with linter rules.

Anecdotally: in my final year of university I took a computational physics class. Many of my classmates wrote their simulations in C or C++. I would rotate between Matlab, Octave and Python. During one of our labs where we wrote particle simulations, I wrote and ran Octave and Python simulations in the time it took my classmates to write their C/C++ versions, and the two fastest simulations in the class were my Octave and Python ones, respectively. (The professor's own sim came in third place). The overhead my classmates had dealing with poorly optimised code that caused constant cache misses was far greater than the interpreter overhead in my code (though at the time I don't think I could have explained why their code was so slow compared to mine).

Honestly most people use Python because it has fantastic libraries. They optimize it because the language is middling, but the libraries are gorgeous

ETA: This might double post because my Internet sucks right now, will fix when I have a chance

This is my two cents as someone in the industry.

Because, while you don't want to nitpick on each instruction cycle, sometimes the code runs millions of times and each microsecond adds up.

Keep in mind that people use this kind of things for work, serving real world customers who are doing their work.

Yes, the language itself is not optimal even by design, but its easy to work with, so they are making it worth a while. There's no shortage of people who can work with it. It is easy to develop and maintain stuff with it, cutting development cost. Yes, we're talking real businesses with real resource constraints.

It comes down to the question "Is YOUR C++ code faster than Python?" (and of course the reverse).

I've built a SCADA from scratch and performance requirements are low to begin with, seeing as it's all network bound and real world objects take time to react, but I'm finding everything is very timely.

A colleague used SQLAlchemy for a similar task and got abysmal performance. No wonder, it's constantly querying the DB for single results.

if isinstance(mylist, list) and not mylist

Problem solved.

Or if not mylist # check if list is empty

Strongly disagree that not x implies to programmers that x is a bool.

That's why we use type-hinting at my company:

    
def do_work(foo: list | None):
    if not foo:
        return
    ...

  

Boom, self-documenting, faster, and very simple.

len(foo) == 0 also doesn't imply it's a list, it could be a dict or any other type that implements the __len__. That matters a lot in most cases, so I highly recommend using type hints instead of relying on assumptions like len(foo) == 0 is probably a list operation.

In my experience, if you didn't write the function that creates the list, there's a solid chance it could be None too, and if you try to check the length of None, you get an error. This is also why returning None when a function fails is bad practice IMO, but that doesn't seem to stop my coworkers.

if you're worried about readability you can leave a comment.

I think it was supposed to be a ~, since they use that in a paragraph below the image.

You'd need to explicitly check for None if using the len() construct as well, so this doesn't change the point of the article.

This is honestly the worst version regarding readability. Don't rely on implicit coercion, people.

You get the length of the stringified length of the array. And a warning if those are enabled.

That's absolutely cursed.

why comment if you don't even want to read the article? python lists are not linked lists, they're contiguous with a smart growth strategy.

So… it has to iterate over the whole empty list is what you’re saying? like once for every of the zero items in the list?