lol this whole article and this thread is a bunch of bikeshedding I haven’t had the privilege of enduring in some weeks.
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().I don’t know about others … but I’m not using Python for execution speed.
Typically the biggest problem in a program is not 100 million calls of
len(x) == 0. If it was, the interpreter could just translate that expression during parsing.I mean, nobody uses Python for execution speed precisely because it is so slow.
This. I rarely boot up Python for the tasks I need to do, and if they are, they are one of the following:
- Assistant code for other coding language
- Throwaway script
- Prototype before using a faster language
Even so,
not xis a pretty nice-to-read pattern, and it’s nice that it’s faster than the less nicelen(x) == 0. I generally do not care to distinguish whether a list isNoneor empty, I just want to know if there’s something there. If I care, then I’ll typically separate those checks anyway:if x is None: ...,if len(x) == 0: ....I prefer the clarity of
len(x) == 0personally; it’s a pretty low syntactic penalty to clarify intent.Obviously, if your variable names are good and you’re consistent about your usage
not listcan be fine too, but it is a very JavaScript-y thing to me to be that vague and/or rely on “truthiness.”The notion of truthiness is defined by the language.
Here are most of the built-in objects considered false:
- constants defined to be false: None and False
- zero of any numeric type: 0, 0.0, 0j, Decimal(0), Fraction(0, 1)
- empty sequences and collections: ‘’, (), [], {}, set(), range(0)
It’s not something that happens to work, it’s literally defined that way.
if not xis the common way to tell if you have data or not, and in most cases, the difference betweenNoneand empty data ([],{}, etc) isn’t important.len(x) == 0will raise an exception if you give itNone, and that’s usually not what you want. So I guess the verbose way to do that isif x is None or len(x) == 0:, but that’s exactly equivalent toif not x, with the small caveat that it doesn’t check if the value has__len__implemented. If you’re getting wonky types thrown around (i.e. getting a class instance when expecting a list), you have bigger problems.I use type hinting on pretty much all “public” methods and functions, and many of my “private” methods and functions as well. As such, sending the wrong types is incredibly unlikely, so
not xis more than sufficient and clearly indicates intent (do I have data?).I did not say it’s not semantically well defined.
https://en.wikipedia.org/wiki/Brainfuck#Hello_World! – this is semantically well defined, but it’s still vague. Vagueness is a property of how well the syntax is conveying intent.
It’s only vague if coming from a language where it’s invalid or vague semantically. For example:
- Javascript -
[]is truthy for whatever reason - C -
int x[] = {};evaluates to true because it’s a pointer; C only evaluates to false if something is 0 - Rust - invalid because you cannot convert a vec -> bool directly, and there’s no concept of null (same w/ Go, but Go has nil, but requires explicit checks)
- Lua - empty tables, zero, and empty strings are truthy; basically, it’s truthy unless it’s
nilorfalse
The only surprising one here is Javascript. I argue Lua and Python make sense for the same reason, Lua just decided to evaluate truthiness based on whether the variable is set, whereas Python decided to evaluate it based on the contents of the variable. I prefer the Python approach here, but I prefer Lua as a language generally (love the simplicity).
- Javascript -
The interpreter can’t make the replacement until it’s about to execute the line as
__bool__and__len__are both (Python’s equivalent of) virtual functions, so it’s got to know the runtime type to know if the substitution is valid. Once it’s that late, it’ll often be faster to execute the requested function than work out if it could execute something faster instead. Even with type hints, it’s possible that a subclass with overridden methods could be passed in, so it’s not safe to do anything until the real runtime type is known.Once there’s a JIT involved, there’s an opportunity to detect the common types passed to a function and call specialised implementations, but I don’t think Python’s JIT is clever enough for this. LuaJIT definitely does this kind of optimisation, though.
Hm… I’ll admit I wasn’t awkward of the
.__len__function.However, does this mean it’s possible to write alen(x) == 0that’s diverges fromnot x?If not, then the substitution is still valid (andnotpresumably also considers the same fundamental. If so, that’s kind of silly.EDIT: I missed the part of your comment about
.__bool__… so yeah in theory you could have something where these two operations are not equivalent.Arguably, you could just say that’s pathological and invalid. Then, still have an optimized path to prefer
not .__bool__()if.__len__() == 0is the comparison you’d be making. Even with the extra interpreter check during evaluation, that would quite possibly be faster if the overhead is truly high.EDIT 2: you’d probably need a little bit more overhead than a straight substitution anyways because you need to maintain the semantic of “if this thing is
Noneit’s not valid if the syntax was originallylen(x).”
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.
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.
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.
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.
I think the explicitness of checking length is worth the performance cost. If ur writing code for speed ur not using python.
Why?
not xmeansx is None or len(x) == 0for lists.len(x) == 0will raise an exception ifxis None. In most cases, the distinction betweenNoneand[]isn’t important, and if it is, I’d expect separate checks for those (again, for explicitness) since you’d presumably handle each case differently.In short:
- if the distinction between
Noneand[]is important, have separate checks - if not,
not xshould be your default, since that way it’s a common pattern for all types
I try to avoid having the same variable with different types I find it is often the cause of difficult to debug bugs. I struggle to think of a case where u would be performing a check that could be an empty list or None where both are expected possible values.
Really? I get that all the time. I do web dev, and our APIs have a lot of optional fields.
I do web dev
Theirs ur problem.
But in all seriousness I think if u def some_func(*args, kwarg=[]) Is a more explicit form of def some_func(*args, kwarg=None)
- if the distinction between
I’d argue that if it’s strict explicitness you want, python is the wrong language.
if not varis a standard pattern in python. You would be making your code slower for no good reason.You always want explicitness when programming. Not everyone reading your code will be deep into Python and relying on falsiness makes it harder to understand.
While I agree to some extent,
if not varis more than clear enough for anyone that knows python. If that pattern confuses someone, they probably aren’t at level where they should be dealing with python at a professional level. The same way you would expect people to understand pointers and references before delving into C code.This sort of stuff is something I taught first year engineering student in their programming introductory course, it’s just how python is written.
For what it’s worth, it’s sort of similar in Erlang/Elixir. If you want to check if a list is empty, checking the length of the list is discouraged. Instead you would use Enum.empty?().
Well, it certainly wouldn’t be the first time that I call some code unnecessarily hard to read and others call it pythonic.
I understand that truthiness has an advantage when you don’t have static types, because it deals somewhat reasonably with most types, and then that is why many experienced Python programmers tend to use it. But I maintain the position that it therefore necessarily also makes it harder to read the code, because you necessarily provide the reader with fewer hints as to what is actually in that variable. It is very much like code using lots of generics in statically typed code.
As for
if Enum.empty?(var), I actually prefer that to checking the length. That syntax in particular, I find a bit too complex – my preferred version isif var.is_empty()– but I still think it makes it easier to read than a length check.
Of course, there’s the nuance that it’s more syntax to remember for actually writing the code. And in particular in dynamically typed languages, your editor may not be able to auto-complete that, so I can understand just not bothering with the extra syntax and doinglen == 0instead. It’s fine.you necessarily provide the reader with fewer hints as to what is actually in that variable
Then make it explicit. I much prefer this:
def do_foo(bar: list | None): if not bar: return ...This one communicates to me that the function only makes sense with a non-empty list.
To this:
def do_foo(bar): if len(bar) == 0: returnThis just tells me
baris something that has a length (list, dict, str, etc).And this is way worse:
def do_foo(bar: list | None): if len(bar) == 0: returnThis tells me we want an exception if
barisNone, which I think is bad style, given that we’re explicitly allowingNonehere. If we remove the| Noneand get an exception, than the code is broken because I shouldn’t be able to get that value in that context.If I care about the difference between
Noneand empty, then I’ll make that explicit:if bar is None: ... if not bar: ...In any case, I just do not like
if len(bar) == 0because that looks like a mistake (i.e. did the dev know it could throw an error if it’s not a list? Was that intentional?).
Containers being “truthy” is quite basic Python and you will find this idiom used in nearly every Python code base in my experience
Yeah, I’m talking less deep than that. Plenty programming beginners will be reading Python code. And personally, I’m a fulltime software engineer, but just don’t do much Python, so while I had it in the back of my mind that Python does truthiness, I would have still thought that
varmust be a boolean, because it’s being negated. Obviously, a different variable name might’ve given me more of a clue, but it really doesn’t reduce mental complexity when I can’t be sure what’s actually in a variable.But if those beginners want to stop being beginners, then they must learn the basics of the language. It makes no more sense to demand that everyone who programs in Python caters to beginners, than it makes to demand that everyone writing in English write at a 3rd grade reading level for the sake of English language learners
Yeah, my stance for both of those is the same: If the complexity aids you in communicating better, then use it. But if you’re using big words where small words would do, then you’re doing a disservice to your readers.
In complex cases where speed is less important than maintainability, I tend to agree.
In this case, a simple comment would suffice. And in fact nothing at all would be okay for any half-competent Python coder, as testing if lists are empty with
if notis super-standard.I never understood that argument. If you can be sure the type is a collection (and this you always should)
not listis so moch easier to read and understood than the length check.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.
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,False0and 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?
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.
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.
But that’s an extra step of logic u must hold in ur head while trying to understand 12 other things.
How many elements in that list? Ah, it’s not list. It’s list, of course, we checked. But it’s not.
