195
Python Performance: Why 'if not list' is 2x Faster Than Using len()
(blog.codingconfessions.com)
this post was submitted on 12 Apr 2025
195 points (90.1% liked)
Technology
69211 readers
4291 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
As a Perl fossil I recognise this syntax as equivalent to
if(not @myarray)which does the same thing. And here I was thinking Guido had deliberately aimed to avoid Perlisms in Python.That said, the Perlism in question is the right* way to do it in Perl. The
lengthoperator does not do the expected thing on an array variable. (You get the length of the stringified length of the array. And a warning if those are enabled.)* You can start a fight with modern Perl hackers with whether
unless(@myarray)is better or just plain wrong, even if it works and is equivalent.That's absolutely cursed.
Well, you see, Perl's
lengthis only for strings and if you want the length of an array, you use@arraynameitself in scalar context.Now,
lengthhappens to provide scalar context to its right hand side, so@arraynamealready returns the required length. Unfortunately, at that point it hasn't been processed bylengthyet, andlengthrequires a string. And so, the length of the array is coerced to be a string and then the length of that string is returned.A case of "don't order fries if your meal already comes with them or you'll end up with too many fries".
it's the string coercion that I have a problem with. I'd much rather have an error than have things silently be coerced to different types.
Perl was originally designed to carry on regardless, and that remains its blessing and curse, a bit like JavaScript which came later.
Unlike JavaScript, if you really want it to throw a warning or even bail out completely at compiling such constructs (at least some of the time, like this one) it's pretty easy to turn that on rather than resort to an entirely different language.
use warnings;at the top of a program and it will punt a warning to STDERR as it carries merrily along.Make that
use warnings FATAL => "syntax";and things that are technically valid but semantically weird like this will throw the error early and also prevent the program from running in the first place.I really liked
unlessin perl; especially as I get older!lengthor something makes that bang really easy to miss. I use!(length)or something instead to visually set it aside.unlessmade this much more visually clear.Empty sequences being false goes back a lot further than perl, it was already a thing in the first lisp (in fact the empty list was the cannonical false).