197
Python Performance: Why 'if not list' is 2x Faster Than Using len()
(blog.codingconfessions.com)
this post was submitted on 12 Apr 2025
197 points (90.5% liked)
Technology
69449 readers
3119 users here now
This is a most excellent place for technology news and articles.
Our Rules
- Follow the lemmy.world rules.
- Only tech related news or articles.
- Be excellent to each other!
- Mod approved content bots can post up to 10 articles per day.
- Threads asking for personal tech support may be deleted.
- Politics threads may be removed.
- No memes allowed as posts, OK to post as comments.
- Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
- Check for duplicates before posting, duplicates may be removed
- Accounts 7 days and younger will have their posts automatically removed.
Approved Bots
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Well fair enough but I still like the fact that len makes the aim and the object more transparent on a quick look through the code which is what I am trying to get at. The supporting argument on bools wasn't't very to the point I agree.
That being said is there an application of "not" on other classes which cannot be replaced by some other more transparent operator (I confess I only know the bool and length context)? I would rather have transparently named operators rather than having to remember what "not" does on ten different types. I like duck typing as much as the next person, but when it is so opaque (name-wise) as in the case of "not", I prefer alternatives.
For instance having open or read on different objects which does really read or open some data vs not some object god knows what it does I should memorise each case.
Truthiness is so fundamental, in most languages, all values have a truthiness, whether they are bool or not. Even in C,
int x = value(); if (!x) x_is_not_zero();is valid and idiomatic.I appreciate the point that calling a method gives more context cues and potentially aids readability, but in this case I feel like
notis the python idiom people expect and reads just fine.I don't know, it throws me off but perhaps because I always use len in this context. Is there any generally applicable practical reason why one would prefer "not" over len? Is it just compactness and being pythonic?
It's very convenient not to have to remember a bunch of different means/methods for performing the same conceptual operation. You might call
len(x) == 0on a list, but next time it's a dict. Time after that it's a complex number. The next time it's an instance.notworks in all cases.I feel like that only serves the purpose up to the point that methods are not over reaching otherwise then it turns into remembering what a method does for a bunch of unrelated objects.
lenalso works on a dict.The point stands. If you want to check if a value is "empty," use the check for whether it's "empty." In Python, that's
not. If you care about different types of empty (e.g.Nonevs[]vs{}), then make those checks explicit. That reads a lot better than doing an explicit check where the more common "empty" check would be correct, and it also make it a lot more obvious when you're doing something special.