One of the principles of the Pythonic style is: simple is better than complex.
But is it when you consider ambiguity and expressiveness too?
len(mylist)tells me it’s definitely a list and not null or whatever. It also tells me the intent of whoever writes the code was checking length.If it requires a long article to explain, I’d certainly be hesitant to use and prefer. The question is, is it surprising or intuitive that the truthy becomes a length check. What do you want to express with your code. And who will read it, and what expectations and requirements do you want to require of them.
For sequence type objects, such as lists, their truth value is False if they are empty.
len(mylist) tells me it’s definitely a list and not null or whatever
Do you know what else can tell you it’s a list? Type hinting.
If I care about the distinction between None and an empty list, I’ll make separate checks.
len(None)raises an exception, and most of the time that’s not what I want when checking whether there’s something in the list, sonot xis generally preferred, especially when type hinting is used consistently enough to be reasonably sure I’m actually getting a list orNone. If I get something else, that means things got really broken and they’ll likely get an exception alter (i.e. when doing anything list-like).For sequence type objects, such as lists, their truth value is False if they are empty.
That’s generally exactly what I want.
len(x) == 0doesn’t tell you it’s a list, it just tells you it has__len__. So that could be adict,list, or a number of other types that have a length, but aren’t lists.Don’t rely on checks like that to tell you what type a thing is.
It’s just how pythonic code is written. All python developers know that
notandboolcan indicate that variable is either empty or null. They will also use theinoperator and other python specific syntax.foo = “potatoes!”
len(foo)
will give you the number of characters in the string. It’s not a surefire way to find a list at all!
Same with dictionaries, iterators (will consume the iterator!), and anything else that has a length.
I’ve actually had the string instead of list issue a number of times, because sometimes things get off and it’s hard to track down where things went wrong.
For this reason, I think type hints are the way to go. Use them consistently w/ a static analysis tool like
pyrightand you’ll catch a lot of these issues before running into cryptic error messages.
Makes perfect sense. If you’re checking if a collection is empty you don’t need to know its exact size. Getting the size can be very inefficient in collections like linked lists or trees, if you have to follow all nodes. To check if it’s empty, all you need fo know if at least one item exists. If one does, there’s no point counting the rest.
People who don’t understand the difference will probably not understand the difference between passing a list and passing an literator/generator to
any().lol this whole article and this thread is a bunch of bikeshedding I haven’t had the privilege of enduring in some weeks.
One more ridiculous fact about the Python to know Thank you for sharing.
While the 2nd approach is not wrong, the first method is considered more Pythonic. Many people don’t agree, but I’ve already put forward my points in a previous article on that debate.
Does Pythonic mean best practice in the python community or “good python”?
If “many people don’t agree”, how can they claim it to be “pythonic”? Isn’t that contradictory?
“Many” isn’t the same as “most,” though I don’t think there’s any way to know what “most” is.
But here’s my reason for agreeing w/ the OP:
not xchecks bothNoneand emptiness, which is usually desiredlen(x) == 0will raise an exception ifxis null- with type hinting, those should be the only two reasonable options
It’s nice that it’s slightly faster, though performance has absolutely nothing to do w/ my preference, though it does have something to do with my preference for avoiding exceptions for non-exceptional cases.