I’d argue that if it’s strict explicitness you want, python is the wrong language. ifnotvar is 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.
While I agree to some extent, ifnotvar is more than clear enough for anyone that knows python. If that pattern confuses someone, they probably aren’t at level where they should be dealing with python at a professional level. The same way you would expect people to understand pointers and references before delving into C code.
This sort of stuff is something I taught first year engineering student in their programming introductory course, it’s just how python is written.
For what it’s worth, it’s sort of similar in Erlang/Elixir. If you want to check if a list is empty, checking the length of the list is discouraged. Instead you would use Enum.empty?().
Well, it certainly wouldn’t be the first time that I call some code unnecessarily hard to read and others call it pythonic.
I understand that truthiness has an advantage when you don’t have static types, because it deals somewhat reasonably with most types, and then that is why many experienced Python programmers tend to use it. But I maintain the position that it therefore necessarily also makes it harder to read the code, because you necessarily provide the reader with fewer hints as to what is actually in that variable. It is very much like code using lots of generics in statically typed code.
As for if Enum.empty?(var), I actually prefer that to checking the length. That syntax in particular, I find a bit too complex – my preferred version is ifvar.is_empty() – but I still think it makes it easier to read than a length check.
Of course, there’s the nuance that it’s more syntax to remember for actually writing the code. And in particular in dynamically typed languages, your editor may not be able to auto-complete that, so I can understand just not bothering with the extra syntax and doing len == 0 instead. It’s fine.
you necessarily provide the reader with fewer hints as to what is actually in that variable
Then make it explicit. I much prefer this:
defdo_foo(bar: list | None):
ifnot bar:
return
...
This one communicates to me that the function only makes sense with a non-empty list.
To this:
defdo_foo(bar):
iflen(bar) == 0:
return
This just tells me bar is something that has a length (list, dict, str, etc).
And this is way worse:
defdo_foo(bar: list | None):
iflen(bar) == 0:
return
This tells me we want an exception if bar is None, which I think is bad style, given that we’re explicitly allowing None here. If we remove the | None and get an exception, than the code is broken because I shouldn’t be able to get that value in that context.
If I care about the difference between None and empty, then I’ll make that explicit:
if bar isNone:
...
ifnot bar:
...
In any case, I just do not like iflen(bar)== 0 because that looks like a mistake (i.e. did the dev know it could throw an error if it’s not a list? Was that intentional?).
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 var must 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
I think you just like the truth test. Frankly I have used Python for over 25 years and have been doing programming for almost 50 years in many different languages. If you think I am somehow a beginner, I would disagree. The truth test is just like so many other Python specific idioms that grow in number by the year. They are not at all obvious unless you are deep into Python. Moreover, the truth test and the len() test are not the same test. One might be able to use either in a specific case, but that is case specific and which is more readable is up to the developer and we may well disagree on that choice. The other consideration in Python, speed of writing code which is often why many of us use Python and that may lead to different choices too including based on habit.
Lot of this reminds me of the Pascal vs. C debate of the 1980’s. Pascal was all about readability over compactness. C on the other hand, seemed to attract people that loved to write very compact code that was almost impossible to figure out on first glance. Me personally, I guess I’d choose C over Pascal but write the C in more of a Pascal authoring philosophy. Similarly, with Python, I often do not go for all of the Python idioms. Lot of that is just writing what I am thinking, and the rest is probably habit. If I am going to test 0 length then I’ll probably test zero length. I do not find it at all obvious that, oh, I want to test 0 length so the Python idiom for that is to truth test. I absolutely know that to be the case on certain types of objects, but it probably is not going to be my first choice.
Yeah, my stance for both of those is the same: If the complexity aids you in communicating better, then use it. But if you’re using big words where small words would do, then you’re doing a disservice to your readers.
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.
While I agree to some extent,
if not varis more than clear enough for anyone that knows python. If that pattern confuses someone, they probably aren’t at level where they should be dealing with python at a professional level. The same way you would expect people to understand pointers and references before delving into C code.This sort of stuff is something I taught first year engineering student in their programming introductory course, it’s just how python is written.
For what it’s worth, it’s sort of similar in Erlang/Elixir. If you want to check if a list is empty, checking the length of the list is discouraged. Instead you would use Enum.empty?().
Well, it certainly wouldn’t be the first time that I call some code unnecessarily hard to read and others call it pythonic.
I understand that truthiness has an advantage when you don’t have static types, because it deals somewhat reasonably with most types, and then that is why many experienced Python programmers tend to use it. But I maintain the position that it therefore necessarily also makes it harder to read the code, because you necessarily provide the reader with fewer hints as to what is actually in that variable. It is very much like code using lots of generics in statically typed code.
As for
if Enum.empty?(var), I actually prefer that to checking the length. That syntax in particular, I find a bit too complex – my preferred version isif var.is_empty()– but I still think it makes it easier to read than a length check.Of course, there’s the nuance that it’s more syntax to remember for actually writing the code. And in particular in dynamically typed languages, your editor may not be able to auto-complete that, so I can understand just not bothering with the extra syntax and doing
len == 0instead. It’s fine.Then make it explicit. I much prefer this:
def do_foo(bar: list | None): if not bar: return ...This one communicates to me that the function only makes sense with a non-empty list.
To this:
def do_foo(bar): if len(bar) == 0: returnThis just tells me
baris something that has a length (list, dict, str, etc).And this is way worse:
def do_foo(bar: list | None): if len(bar) == 0: returnThis tells me we want an exception if
barisNone, which I think is bad style, given that we’re explicitly allowingNonehere. If we remove the| Noneand get an exception, than the code is broken because I shouldn’t be able to get that value in that context.If I care about the difference between
Noneand empty, then I’ll make that explicit:if bar is None: ... if not bar: ...In any case, I just do not like
if len(bar) == 0because that looks like a mistake (i.e. did the dev know it could throw an error if it’s not a list? Was that intentional?).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
I think you just like the truth test. Frankly I have used Python for over 25 years and have been doing programming for almost 50 years in many different languages. If you think I am somehow a beginner, I would disagree. The truth test is just like so many other Python specific idioms that grow in number by the year. They are not at all obvious unless you are deep into Python. Moreover, the truth test and the len() test are not the same test. One might be able to use either in a specific case, but that is case specific and which is more readable is up to the developer and we may well disagree on that choice. The other consideration in Python, speed of writing code which is often why many of us use Python and that may lead to different choices too including based on habit.
Lot of this reminds me of the Pascal vs. C debate of the 1980’s. Pascal was all about readability over compactness. C on the other hand, seemed to attract people that loved to write very compact code that was almost impossible to figure out on first glance. Me personally, I guess I’d choose C over Pascal but write the C in more of a Pascal authoring philosophy. Similarly, with Python, I often do not go for all of the Python idioms. Lot of that is just writing what I am thinking, and the rest is probably habit. If I am going to test 0 length then I’ll probably test zero length. I do not find it at all obvious that, oh, I want to test 0 length so the Python idiom for that is to truth test. I absolutely know that to be the case on certain types of objects, but it probably is not going to be my first choice.
Yeah, my stance for both of those is the same: If the complexity aids you in communicating better, then use it. But if you’re using big words where small words would do, then you’re doing a disservice to your readers.