There is no need to add a None check, as foo being None should be considered as a faulty input. Avoiding the possibility of foo being None from the beginning using static checks or testing is of course the preferred solution. But in reality we do not work in such optimal environments, at least I can say that from the perspective of data science, where often procedural, untested code is produced that runs only a few times. But I get your point and I think both paths are viable, but I am also okay with being in the wrong here,
That’s terrible, and I would block that PR in a heartbeat, unless there was a very good reason for it (given context). I would instead prefer:
if foo isNone:
...
Exceptions are useful for bubbling up errors, they’re a massive code smell if you’re catching something thrown by local logic. Just like you shouldn’t catch IndexError right after indexing a list, you shouldn’t catch TypeError right after checking the length. If you need to check parameters, check them at the start of your function and return early.
Rejecting a PR shouldn’t be offensive, it should be a learning opportunity, both for the reviewer and the submitter. If I reject it, I’ll give a clear reason why, and suggestions on how to fix it. I’ll also engage in conversation if you’re not clear on why I made a given comment, as well as a defense for why your code should be accepted as-is (i.e. that context I’m talking about).
So please bother me with terrible, terrible code. I want to take time out of my day to help contributors learn, and I like pointing out areas where I learn something as well (like, “hey, this is really clever and also really easy to read, good job!”). I’m not always right, but I do have a lot of experience that I think others could benefit from. I know I was deeply appreciative of constructive criticism as a new dev, and I hope that’s true for the people I provide reviews for.
My point is that if your variable can be
Nonethen you need the same pattern for the length check.So for the Pythonic version:
if (foo is not None) and not foo: ...For the explicit length check:
if (foo is not None) and (len(foo) == 0): ...Honestly you’re probably better off using type hints and catching such things with static checks and not adding the
Nonecheck.This is what I would come up with:
There is no need to add a
Nonecheck, asfoobeingNoneshould be considered as a faulty input. Avoiding the possibility offoobeingNonefrom the beginning using static checks or testing is of course the preferred solution. But in reality we do not work in such optimal environments, at least I can say that from the perspective of data science, where often procedural, untested code is produced that runs only a few times. But I get your point and I think both paths are viable, but I am also okay with being in the wrong here,That’s terrible, and I would block that PR in a heartbeat, unless there was a very good reason for it (given context). I would instead prefer:
if foo is None: ...Exceptions are useful for bubbling up errors, they’re a massive code smell if you’re catching something thrown by local logic. Just like you shouldn’t catch
IndexErrorright after indexing a list, you shouldn’t catchTypeErrorright after checking the length. If you need to check parameters, check them at the start of your function and return early.Sir, I will make sure to never bother you with a PR and my terrible, terrible code ;)
Rejecting a PR shouldn’t be offensive, it should be a learning opportunity, both for the reviewer and the submitter. If I reject it, I’ll give a clear reason why, and suggestions on how to fix it. I’ll also engage in conversation if you’re not clear on why I made a given comment, as well as a defense for why your code should be accepted as-is (i.e. that context I’m talking about).
So please bother me with terrible, terrible code. I want to take time out of my day to help contributors learn, and I like pointing out areas where I learn something as well (like, “hey, this is really clever and also really easy to read, good job!”). I’m not always right, but I do have a lot of experience that I think others could benefit from. I know I was deeply appreciative of constructive criticism as a new dev, and I hope that’s true for the people I provide reviews for.