Besides, I see c code all the time that treats pointers as bool for the purposes of an if statement. !pointer is very common and no one thinks that means pointer it’s exclusively a Boolean concept.
Maybe, but that serves as a very valuable teaching opportunity about the concept of “empty” is in Python. It’s pretty intuitive IMO, and it can make a lot of things more clear once you understand that.
That said, larger projects should be using type hints everywhere, and that should make the intention here painfully obvious:
defdo_work(foo: list | None):
ifnot foo:
... handle empty list ...
...
That’s obviously not a boolean, but it’s being treated as one. If the meaning there isn’t obvious, then look it up/ask someone about Python semantics.
I’m generally not a fan of learning a ton of jargon/big frameworks to get the benefits of more productivity (e.g. many design patterns are a bit obtuse IMO), but learning language semantics that are used pretty much everywhere seems pretty reasonable to me. And it’s a lot nicer than doing something like this everywhere:
I would say it depends heavily on the language. In Python, it’s very common that different objects have some kind of Boolean interpretation, so assuming that an object is a bool because it is used in a Boolean context is a bit silly.
Well 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 person, but when it is so opaque (name-wise) 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.
Truthiness is so fundamental, in most languages, 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.
I appreciate the point that calling a method gives more context cues and potentially aids readability, but in this case I feel like not is the python idiom people expect and reads just fine.
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?
It’s very convenient not to have to remember a bunch of different means/methods for performing the same conceptual operation. You might call len(x) == 0 on a list, but next time it’s a dict. Time after that it’s a complex number. The next time it’s an instance. not works in all cases.
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. None vs [] 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.
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.
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.
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?
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 isTrue or x isFalse if x should be a Boolean. In that sense, if I read if x or if not x, it’s an indicator that x does not need to be a Boolean.
In that sense, I could say that my preference is to flip it (in Python): Explicitly indicate/check for a Boolean if you expect/need a Boolean, otherwise use a “truethiness” check.
ifnot x then … end is very common in Lua for similar purposes, very rarely do you see hard nil comparisons or calls to typeof (last time I did was for a serializer).
i haven’t programmed since college 15 years ago and even i know that 0 == false for non bool variables. what kind of professional programmers wouldn’t know that?
Strongly disagree that
not ximplies to programmers thatxis a bool.In context, one can consider it a bool.
Besides, I see c code all the time that treats pointers as bool for the purposes of an if statement. !pointer is very common and no one thinks that means pointer it’s exclusively a Boolean concept.
Maybe, but that serves as a very valuable teaching opportunity about the concept of “empty” is in Python. It’s pretty intuitive IMO, and it can make a lot of things more clear once you understand that.
That said, larger projects should be using type hints everywhere, and that should make the intention here painfully obvious:
def do_work(foo: list | None): if not foo: ... handle empty list ... ...That’s obviously not a boolean, but it’s being treated as one. If the meaning there isn’t obvious, then look it up/ask someone about Python semantics.
I’m generally not a fan of learning a ton of jargon/big frameworks to get the benefits of more productivity (e.g. many design patterns are a bit obtuse IMO), but learning language semantics that are used pretty much everywhere seems pretty reasonable to me. And it’s a lot nicer than doing something like this everywhere:
if foo is None or len(foo) == 0:It does if you are used to sane languages instead of the implicit conversion nonsense C and the “dynamic” languages are doing
well it does not imply directly per se since you can “not” many things but I feel like my first assumption would be it is used in a bool context
I would say it depends heavily on the language. In Python, it’s very common that different objects have some kind of Boolean interpretation, so assuming that an object is a bool because it is used in a Boolean context is a bit silly.
Well 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 person, but when it is so opaque (name-wise) 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.
Truthiness is so fundamental, in most languages, 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.I appreciate the point that calling a method gives more context cues and potentially aids readability, but in this case I feel like
notis the python idiom people expect and reads just fine.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?
It’s very convenient not to have to remember a bunch of different means/methods for performing the same conceptual operation. You might call
len(x) == 0on a list, but next time it’s a dict. Time after that it’s a complex number. The next time it’s an instance.notworks in all cases.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.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.
I definitely agree that
lenis 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.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?
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 thatxdoes not need to be a Boolean.In that sense, I could say that my preference is to flip it (in Python): Explicitly indicate/check for a Boolean if you expect/need a Boolean, otherwise use a “truethiness” check.
if not x then … endis very common in Lua for similar purposes, very rarely do you see hard nil comparisons or calls totypeof(last time I did was for a serializer).You can make that assumption at your own peril.
I don’t think they are a minority
If anything len tells you that it is a sequence or a collection, “not” does not tell you that. That I feel like is the main point of my objection.
deleted by creator
Doesn’t matter what it implies. The entire purpose of programming is to make it so a human doesn’t have to go do something manually.
not xtells me I need to go manually check what typexis in Python.len(x) == 0tells me that it’s being type-checked automaticallyThat’s just not true:
not x- has an empty value (None, False,[],{}, etc)len(x) == 0- has a length (list,dict,tuple, etc, or even a custom type implementing__len__)You can probably assume it’s iterable, but that’s about it.
But why assume? You can easily just document the type with a type-hint:
def do_work(foo: list | None): if not foo: return ...i haven’t programmed since college 15 years ago and even i know that 0 == false for non bool variables. what kind of professional programmers wouldn’t know that?