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.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
Assuming an equivalent package is produced, what’s the maintenance cost (factoring in coder availability) difference between the Python vs faster language implementations?
^^ therein lies the rub
Reminds of the expression,
premature optimization is the root of all evilif not swimming in funding, might be a darwinic move to choose the faster language and have to code everything yourself from scratch
I think the explicitness of checking length is worth the performance cost. If ur writing code for speed ur not using python.
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.
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
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)
def some_func(*args, kwarg=[])
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.
- if the distinction between
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.
