I definitely agree that len is the preferred choice for checking the emptiness of an object, for the reasons you mention. I’m just pointing out that assuming a variable is a bool because it’s used in a Boolean context is a bit silly, especially in Python or other languages where any object can have a truthiness value, and where this is commonly utilised.
Comment on Python Performance: Why 'if not list' is 2x Faster Than Using len()
iAvicenna@lemmy.world 5 days agoWell fair enough but I still like the fact that len makes the aim and the object more transparent on a quick look through the code which is what I am trying to get at. The supporting argument on bools wasn’t’t very to the point I agree.
That being said is there an application of “not” on other classes which cannot be replaced by some other more transparent operator (I confess I only know the bool and length context)? I would rather have transparently named operators rather than having to remember what “not” does on ten different types. I like duck typing as much as the next guy, but when it is so opaque as in the case of not, I prefer alternatives. For instance having open or read on different objects which does really read or open some data vs not some object god knows what it does I should memorise each case.
thebestaquaman@lemmy.world 4 days ago
iAvicenna@lemmy.world 4 days ago
It is not “assume” as in a conscious “this is probably a bool I will assume so” but more like a slip of attention by someone who is more used to the bool context of not. Is “not integer” or “not list” really that commonly used that it is even comparable to its usage in bool context?
thebestaquaman@lemmy.world 4 days ago
Then I absolutely understand you :)
How common it is 100 % depends on the code base and what practices are preferred. In Python code bases where I have a word in decisions, all Boolean checks should be
x is Trueorx is Falseifxshould be a Boolean. In that sense, if I readif xorif not x, it’s an indicator thatxdoesn’t need to be a Boolean.
jerkface@lemmy.ca 5 days ago
Truthiness is so fundamental, all values have a truthiness, whether they are bool or not. Even in C,
int x = value(); if (!x) x_is_not_zero();is valid and idiomatic.iAvicenna@lemmy.world 5 days ago
I don’t know, it throws me off but perhaps because I always use len in this context. Is there any generally applicable practical reason why one would prefer “not” over len? Is it just compactness and being pythonic?
jerkface@lemmy.ca 4 days ago
iAvicenna@lemmy.world 4 days ago
I feel like that only serves the purpose up to the point that methods are not over reaching otherwise then it turns into remembering what a method does for a bunch of unrelated objects.
sugar_in_your_tea@sh.itjust.works 3 days ago
lenalso works on a dict.The point stands. If you want to check if a value is “empty,” use the check for whether it’s “empty.” In Python, that’s
not. If you care about different types of empty (e.g.Nonevs[]vs{}), then make those checks explicit. That reads a lot better than doing an explicit check where the more common “empty” check would be correct, and it also make it a lot more obvious when you’re doing something special.