Why? not x means x isNoneorlen(x) == 0 for lists. len(x) == 0 will raise an exception if x is None. In most cases, the distinction between None and [] 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 None and [] is important, have separate checks
if not, not x should 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.
I like the exception being raised their is no reason I should be passing in None to the function it means I’ve fucked up the value of whatever I’m passing in at some point.
if l isNone:
raise ValueError("Must provide a valid value for...")
Having an attribute or type error rarely provides the right amount of context to immediately recognize the error, especially if it’s deep inside the application. A lot of our old code makes stupid errors like TypeError: operator - not defined on types NoneType andfloat, because someone screwed up somewhere and wasn’t strict on checks. Don’t reply on implicit exceptions, explicitly raise them so you can add context, because sometimes stacktraces get lost and all you have is the error message.
But in my experience, the practical difference between [] and None is essentially zero, except in a few cases, and those should stand out. I have a few places with logic like this:
if l isNone:
raise MyCustomInvalidException("Must provide a list")
ifnot l:
# nothing to doreturn
For example, if I make a task runner, an empty list could validly mean no arguments, while a null list means the caller screwed up somewhere and probably forgot to provide them.
Explicit is better than implicit, and simple is better than complex.
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:
Noneand[]is important, have separate checksnot xshould be your default, since that way it’s a common pattern for all typesI 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.
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)
Don’t do this:
def fun(l=[]): l.append(len(l)) return l fun() # [0] fun() # [0, 1] fun(l=[]) # [0] fun() # [0, 1, 2] fun(l=None) # raise AttributeError or TypeError if len(l) comes firstThis can be downright cryptic if you’re passing things dynamically, such as:
def caller(*args, **kwargs): fun(*args, **kwargs)It’s much safer to do a simple check at the beginning:
if not l: l = []I like the exception being raised their is no reason I should be passing in None to the function it means I’ve fucked up the value of whatever I’m passing in at some point.
Oh no a stray None! Take cover …
Robust codebase should never fail from a stray None
Chaos testing is specifically geared towards bullet proofing code against unexpected param types including None.
The only exception is for private support function for type specific checking functions. Where it’s obviously only for one type ever.
We live in clownworld, i’m a clown and keep the company of shit throwing monkeys.
Ur function args if fucked up should always throw an error that’s the entire point of python type hints
Then make it explicit:
if l is None: raise ValueError("Must provide a valid value for...")Having an attribute or type error rarely provides the right amount of context to immediately recognize the error, especially if it’s deep inside the application. A lot of our old code makes stupid errors like
TypeError: operator - not defined on types NoneType and float, because someone screwed up somewhere and wasn’t strict on checks. Don’t reply on implicit exceptions, explicitly raise them so you can add context, because sometimes stacktraces get lost and all you have is the error message.But in my experience, the practical difference between
[]andNoneis essentially zero, except in a few cases, and those should stand out. I have a few places with logic like this:if l is None: raise MyCustomInvalidException("Must provide a list") if not l: # nothing to do returnFor example, if I make a task runner, an empty list could validly mean no arguments, while a null list means the caller screwed up somewhere and probably forgot to provide them.
Explicit is better than implicit, and simple is better than complex.