I'd argue that if it's strict explicitness you want, python is the wrong language. if not var is a standard pattern in python. You would be making your code slower for no good reason.

[–] [email protected] 11 points 1 day ago (8 children)

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.

[–] UndercoverUlrikHD 5 points 12 hours ago (1 children)

While I agree to some extent, if not var 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?().

[–] [email protected] 2 points 11 hours ago (1 children)

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 if 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 == 0 instead. It's fine.

[–] [email protected] 2 points 10 hours ago

you necessarily provide the reader with fewer hints as to what is actually in that variable

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:
        return

This just tells me bar is something that has a length (list, dict, str, etc).

And this is way worse:

def do_foo(bar: list | None):
    if len(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 is None:
    ...
if not bar:
    ...

In any case, I just do not like if len(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?).

load more comments (6 replies)

load more comments (19 replies)