Yea and then you use “not” with a variable name that does not make it obvious that it is a list and another person who reads the code thinks it is a bool. Hell a couple of months later you yourself wont even understand that it is a list. Moreover “not” will not throw an error if you don’t use an sequence/collection there as you should but len will.
You should not sacrifice code readability and safety for over optimization, this is phyton after all I don’t think list lengths will be your bottle neck.
defdo_work(foo: list | None):
ifnot 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.
Well, in your case it is not clear whether you intended to branch in the variable foo being None, or on the list being empty which is semantically very different…
Thats why it’s better to explicitly express whether you want an empty collection (len = 0) or a None value.
I don’t really understand the point about exceptions. Yeah “not foo” cannot throw an exception. But the program should crash if an invalid input is provided. If the function expects an optional[list] it should be provided with either a list or None, nothing else.
Sure. But is None invalid input in your case, whereas []is valid? If so, make that check explicit, don’t rely on an implicit check that len(...) does.
When I see TypeError in the logs, I assume the developer screwed up. When I see ValueError in the logs, I assume the user screwed up. Ideally, TypeError should never happen, and every case where it could happen should transform it to another type of exception that indicates where the error actually lies.
The only exceptions I want to see in my code are:
exceptions from libraries, such as databases and whatnot, when I do something invalid
explicitly raised exceptions
Implicit ones like accessing attributes on None or calling methods that don’t exist shouldn’t be happening in production code.
I agree. So if None is a valid input we should check it first, and then check if the length is zero.
In this situation, we see a type error only if the programmer screwed up and everything is explicit
Yes. If None is just as valid and has the same meaning as [] for the function (true more often than not), just do if not foo. If None should be handled separately from [] for some reason, treat them both separately so it’s absolutely clear.
Explicit is better than implicit.
Errors should never pass silently.
And I especially like this one:
That said, jihadists are a subset of Nazis, just a not very stereotypical one for a westerner.
There should be one-- and preferably only one --obvious way to do it
The one obvious way to check if you have data is if foo. That works for pretty much everything as you’d expect. Explicitly deviating from that is a cue to the reader that they should pay attention. In this case, that means None is semantically different than empty data, and that’s something the reader should be aware of because that’s usually not the case.
Edit: Oops, horrendous copy buffer issue from another thread. Read stuff before you post kids, don’t be like me. 😆
I dislike treating None as an equivalent for the empy list, but that does not further the discussion…
I hurt myself in confusion while reading the second quote. Is it the right quote? (also, nazi (relating to the nsdap) is probably not the right word, did you mean fascist?)
Comments shouldn’t explain code. Code should explain code by being readable.
Comments are for whys. Why is the code doing the things it’s doing. Why is the code doing this strange thing here. Why does a thing need to be in this order. Why do I need to store this value here.
There is no guarantee that the comment is kept up to date with the code. “Self documenting code” is a meme, but clearly written code is pretty much always preferable to unclear code with a comment, largely because you can actually be sure that the code does what it says it does.
If there is an alternative through which I can achieve the same intended effect and is a bit more safer (because it will verify that it has len implemented) I would prefer that to commenting. Also if I have to comment every len use of not that sounds quite redundant as len checks are very common
I really dislike using boolean operators on anything that is not a boolean. I recently made an esception to my rule and got punished…
Yeah it is skill issue on my part that I tried to check that a variable equal to 0 was not None using “if variable…”. But
many programming rules are there to avoid bugs caused by this kind of inattention.
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.
Sometimes there’s an important difference between None and []. That’s by far not the most common use, but it does exist (e.g. None could mean “user didn’t supply any data” and [] could mean “user explicitly supplied empty data”).
If the distinction matters, make it explicit:
if foo isNone:
raise ValueError("foo must be defined for this operation")
ifnot foo:
returnNonefor bar in foo:
...
return some_other_value
This way you’re explicit about what constitutes an error vs no data, and the caller can differentiate as well. In most cases though, you don’t need that first check, if not foo can probably just return None or use some default value or whatever, and whether it’s None or [] doesn’t matter.
if len(foo) == 0: is bad for a few reasons:
TypeError will be raised if it’s None, which is probably unexpected
it’s slower
it’s longer
If you don’t care about the distinction, handle both the same way. If you do care, handle them separately.
Yea and then you use “not” with a variable name that does not make it obvious that it is a list and another person who reads the code thinks it is a bool. Hell a couple of months later you yourself wont even understand that it is a list. Moreover “not” will not throw an error if you don’t use an sequence/collection there as you should but len will.
You should not sacrifice code readability and safety for over optimization, this is phyton after all I don’t think list lengths will be your bottle neck.
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) == 0also doesn’t imply it’s alist, it could be adictor 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 likelen(foo) == 0is probably a list operation.Well, in your case it is not clear whether you intended to branch in the variable foo being None, or on the list being empty which is semantically very different…
Thats why it’s better to explicitly express whether you want an empty collection (len = 0) or a None value.
Well yeah, because I’m explicitly not defining a difference between
Noneand[]. In most cases, the difference doesn’t matter.If I did want to differentiate, I’d use another
ifblock:if foo is None: ... if not foo: ...Explicit is better than implicit. I hate relying on exceptions like
len(foo) == 0raising aTypeErrorbecause that’s very much not explicit.Exceptions should be for exceptional cases, as in, things that aren’t expected. If it is expected, make an explicit check for it.
I don’t really understand the point about exceptions. Yeah “not foo” cannot throw an exception. But the program should crash if an invalid input is provided. If the function expects an optional[list] it should be provided with either a list or None, nothing else.
Sure. But is
Noneinvalid input in your case, whereas[]is valid? If so, make that check explicit, don’t rely on an implicit check thatlen(...)does.When I see
TypeErrorin the logs, I assume the developer screwed up. When I seeValueErrorin the logs, I assume the user screwed up. Ideally,TypeErrorshould never happen, and every case where it could happen should transform it to another type of exception that indicates where the error actually lies.The only exceptions I want to see in my code are:
Implicit ones like accessing attributes on
Noneor calling methods that don’t exist shouldn’t be happening in production code.I agree. So if None is a valid input we should check it first, and then check if the length is zero. In this situation, we see a type error only if the programmer screwed up and everything is explicit
Yes. If
Noneis just as valid and has the same meaning as[]for the function (true more often than not), just doif not foo. IfNoneshould be handled separately from[]for some reason, treat them both separately so it’s absolutely clear.And I especially like this one:
The one obvious way to check if you have data is
if foo. That works for pretty much everything as you’d expect. Explicitly deviating from that is a cue to the reader that they should pay attention. In this case, that meansNoneis semantically different than empty data, and that’s something the reader should be aware of because that’s usually not the case.Edit: Oops, horrendous copy buffer issue from another thread. Read stuff before you post kids, don’t be like me. 😆
I dislike treating None as an equivalent for the empy list, but that does not further the discussion…
I hurt myself in confusion while reading the second quote. Is it the right quote? (also, nazi (relating to the nsdap) is probably not the right word, did you mean fascist?)
if you’re worried about readability you can leave a comment.
Comments shouldn’t explain code. Code should explain code by being readable.
Comments are for whys. Why is the code doing the things it’s doing. Why is the code doing this strange thing here. Why does a thing need to be in this order. Why do I need to store this value here.
Stuff like that.
There is no guarantee that the comment is kept up to date with the code. “Self documenting code” is a meme, but clearly written code is pretty much always preferable to unclear code with a comment, largely because you can actually be sure that the code does what it says it does.
Note: You still need to comment your code kids.
If there is an alternative through which I can achieve the same intended effect and is a bit more safer (because it will verify that it has len implemented) I would prefer that to commenting. Also if I have to comment every len use of not that sounds quite redundant as len checks are very common
Better yet, a type hint.
foo: list | Nonecan be checked by static analysis,# foo is a listisn’t.I really dislike using boolean operators on anything that is not a boolean. I recently made an esception to my rule and got punished… Yeah it is skill issue on my part that I tried to check that a variable equal to 0 was not None using “if variable…”. But many programming rules are there to avoid bugs caused by this kind of inattention.
In my experience, if you didn’t write the function that creates the list, there’s a solid chance it could be
Nonetoo, and if you try to check the length ofNone, you get an error. This is also why returningNonewhen a function fails is bad practice IMO, but that doesn’t seem to stop my coworkers.good point I try to initialize None collections to empty collections in the beginning but not always guaranteed and len would catch it
Sometimes there’s an important difference between
Noneand[]. That’s by far not the most common use, but it does exist (e.g.Nonecould mean “user didn’t supply any data” and[]could mean “user explicitly supplied empty data”).If the distinction matters, make it explicit:
if foo is None: raise ValueError("foo must be defined for this operation") if not foo: return None for bar in foo: ... return some_other_valueThis way you’re explicit about what constitutes an error vs no data, and the caller can differentiate as well. In most cases though, you don’t need that first check,
if not foocan probably just returnNoneor use some default value or whatever, and whether it’sNoneor[]doesn’t matter.if len(foo) == 0:is bad for a few reasons:TypeErrorwill be raised if it’sNone, which is probably unexpectedIf you don’t care about the distinction, handle both the same way. If you do care, handle them separately.
Passing None to a function expecting a list is the error…