this post was submitted on 12 Apr 2025
194 points (90.1% liked)

Technology

68813 readers
5226 users here now

This is a most excellent place for technology news and articles.

Our Rules

  1. Follow the lemmy.world rules.
  2. Only tech related news or articles.
  3. Be excellent to each other!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
  9. Check for duplicates before posting, duplicates may be removed
  10. Accounts 7 days and younger will have their posts automatically removed.

Approved Bots

founded 2 years ago
MODERATORS
L3s@lemmy.world
enu@lemmy.world
technopagan@lemmy.world
L4s@lemmy.world
L3s@hackingne.ws
L4s@hackingne.ws
194
Python Performance: Why 'if not list' is 2x Faster Than Using len() (blog.codingconfessions.com)
submitted 4 days ago by abhi9u@lemmy.world to c/technology@lemmy.world
150 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] iAvicenna@lemmy.world 28 points 4 days ago* (last edited 4 days ago) (5 children)

Yea and then you use "not" with a variable name that does not make it obvious that it is a list and another person who reads the code thinks it is a bool. Hell a couple of months later you yourself wont even understand that it is a list. Moreover "not" will not throw an error if you don't use an sequence/collection there as you should but len will.

You should not sacrifice code readability and safety for over optimization, this is phyton after all I don't think list lengths will be your bottle neck.

[–] jerkface@lemmy.ca 15 points 4 days ago (6 children)

Strongly disagree that not x implies to programmers that x is a bool.

[–] taladar@sh.itjust.works 7 points 4 days ago

It does if you are used to sane languages instead of the implicit conversion nonsense C and the "dynamic" languages are doing

[–] iAvicenna@lemmy.world 6 points 4 days ago (3 children)

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

[–] thebestaquaman@lemmy.world 8 points 4 days ago (2 children)

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.

[–] iAvicenna@lemmy.world 4 points 4 days ago* (last edited 4 days ago) (2 children)

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.

[–] jerkface@lemmy.ca 5 points 4 days ago* (last edited 4 days ago) (1 children)

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.

[–] iAvicenna@lemmy.world 2 points 4 days ago (1 children)

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 1 points 4 days ago* (last edited 4 days ago) (2 children)

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.

[–] sugar_in_your_tea@sh.itjust.works 1 points 3 days ago

dict

len also 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. 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.

[–] iAvicenna@lemmy.world 2 points 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.

[–] thebestaquaman@lemmy.world 1 points 3 days ago (1 children)

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.

[–] iAvicenna@lemmy.world 1 points 3 days ago (1 children)

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 1 points 3 days ago* (last edited 3 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 True or x is False 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.

[–] Glitchvid@lemmy.world 2 points 4 days ago

if not 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).

[–] catloaf@lemm.ee 3 points 4 days ago (2 children)

You can make that assumption at your own peril.

[–] WhyJiffie@sh.itjust.works 4 points 4 days ago

I don't think they are a minority

[–] iAvicenna@lemmy.world 3 points 4 days ago

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.

[–] jj4211@lemmy.world 1 points 3 days ago

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.

[–] sugar_in_your_tea@sh.itjust.works 1 points 3 days ago

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:
[–] JustAnotherKay@lemmy.world 1 points 3 days ago (1 children)

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 x tells me I need to go manually check what type x is in Python.

len(x) == 0 tells me that it's being type-checked automatically

[–] sugar_in_your_tea@sh.itjust.works 1 points 3 days ago

That'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
    ...
[–] acosmichippo@lemmy.world 1 points 3 days ago* (last edited 3 days ago)

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?

[–] sugar_in_your_tea@sh.itjust.works 3 points 3 days ago* (last edited 3 days ago) (1 children)

That's why we use type-hinting at my company:

def do_work(foo: list | None):
    if not foo:
        return
    ...

Boom, self-documenting, faster, and very simple.

len(foo) == 0 also doesn't imply it's a list, it could be a dict or any other type that implements the __len__. That matters a lot in most cases, so I highly recommend using type hints instead of relying on assumptions like len(foo) == 0 is probably a list operation.

[–] LegoBrickOnFire@lemmy.world 1 points 3 days ago* (last edited 3 days ago) (1 children)

Well, in your case it is not clear whether you intended to branch in the variable foo being None, or on the list being empty which is semantically very different...

Thats why it's better to explicitly express whether you want an empty collection (len = 0) or a None value.

[–] sugar_in_your_tea@sh.itjust.works 2 points 3 days ago (1 children)

Well yeah, because I'm explicitly not defining a difference between None and []. In most cases, the difference doesn't matter.

If I did want to differentiate, I'd use another if block:

if foo is None:
    ...
if not foo:
    ...

Explicit is better than implicit. I hate relying on exceptions like len(foo) == 0 raising a TypeError because that's very much not explicit.

Exceptions should be for exceptional cases, as in, things that aren't expected. If it is expected, make an explicit check for it.

[–] LegoBrickOnFire@lemmy.world 1 points 3 days ago (1 children)

I don't really understand the point about exceptions. Yeah "not foo" cannot throw an exception. But the program should crash if an invalid input is provided. If the function expects an optional[list] it should be provided with either a list or None, nothing else.

[–] sugar_in_your_tea@sh.itjust.works 1 points 3 days ago* (last edited 3 days ago) (1 children)

Sure. But is None invalid input in your case, whereas [] is valid? If so, make that check explicit, don't rely on an implicit check that len(...) does.

When I see TypeError in the logs, I assume the developer screwed up. When I see ValueError in the logs, I assume the user screwed up. Ideally, TypeError should never happen, and every case where it could happen should transform it to another type of exception that indicates where the error actually lies.

The only exceptions I want to see in my code are:

  • exceptions from libraries, such as databases and whatnot, when I do something invalid
  • explicitly raised exceptions

Implicit ones like accessing attributes on None or calling methods that don't exist shouldn't be happening in production code.

[–] LegoBrickOnFire@lemmy.world 1 points 3 days ago (1 children)

I agree. So if None is a valid input we should check it first, and then check if the length is zero. In this situation, we see a type error only if the programmer screwed up and everything is explicit

[–] sugar_in_your_tea@sh.itjust.works 1 points 3 days ago* (last edited 3 days ago) (1 children)

Yes. If None is just as valid and has the same meaning as [] for the function (true more often than not), just do if not foo. If None should be handled separately from [] for some reason, treat them both separately so it's absolutely clear.

Explicit is better than implicit.
Errors should never pass silently.

And I especially like this one:

~~That said, jihadists are a subset of Nazis, just a not very stereotypical one for a westerner.~~

There should be one-- and preferably only one --obvious way to do it

The one obvious way to check if you have data is if foo. That works for pretty much everything as you'd expect. Explicitly deviating from that is a cue to the reader that they should pay attention. In this case, that means None is semantically different than empty data, and that's something the reader should be aware of because that's usually not the case.

Edit: Oops, horrendous copy buffer issue from another thread. Read stuff before you post kids, don't be like me. 😆

[–] LegoBrickOnFire@lemmy.world 1 points 3 days ago (1 children)

I dislike treating None as an equivalent for the empy list, but that does not further the discussion...

I hurt myself in confusion while reading the second quote. Is it the right quote? (also, nazi (relating to the nsdap) is probably not the right word, did you mean fascist?)

[–] sugar_in_your_tea@sh.itjust.works 1 points 3 days ago

Oops, copied from another thread apparently. Apparently my copy didn't... copy. Here's what it should be:

There should be one-- and preferably only one --obvious way to do it.

I'll fix my original comment so it's less confusing, but not in a way that makes you look like an idiot. :)

[–] LegoBrickOnFire@lemmy.world 1 points 3 days ago

I really dislike using boolean operators on anything that is not a boolean. I recently made an esception to my rule and got punished... Yeah it is skill issue on my part that I tried to check that a variable equal to 0 was not None using "if variable...". But many programming rules are there to avoid bugs caused by this kind of inattention.

[–] Artyom@lemm.ee 1 points 3 days ago (2 children)

In my experience, if you didn't write the function that creates the list, there's a solid chance it could be None too, and if you try to check the length of None, you get an error. This is also why returning None when a function fails is bad practice IMO, but that doesn't seem to stop my coworkers.

[–] LegoBrickOnFire@lemmy.world 1 points 3 days ago

Passing None to a function expecting a list is the error...

[–] iAvicenna@lemmy.world 1 points 3 days ago* (last edited 3 days ago) (1 children)

good point I try to initialize None collections to empty collections in the beginning but not always guaranteed and len would catch it

[–] sugar_in_your_tea@sh.itjust.works 1 points 3 days ago

Sometimes there's an important difference between None and []. That's by far not the most common use, but it does exist (e.g. None could mean "user didn't supply any data" and [] could mean "user explicitly supplied empty data").

If the distinction matters, make it explicit:

if foo is None:
    raise ValueError("foo must be defined for this operation")
if not foo:
    return None

for bar in foo:
    ...

return some_other_value

This way you're explicit about what constitutes an error vs no data, and the caller can differentiate as well. In most cases though, you don't need that first check, if not foo can probably just return None or use some default value or whatever, and whether it's None or [] doesn't matter.

if len(foo) == 0: is bad for a few reasons:

  • TypeError will be raised if it's None, which is probably unexpected
  • it's slower
  • it's longer

If you don't care about the distinction, handle both the same way. If you do care, handle them separately.

[–] acosmichippo@lemmy.world -2 points 4 days ago (4 children)

if you're worried about readability you can leave a comment.

[–] chunkystyles@sopuli.xyz 2 points 3 days ago

Comments shouldn't explain code. Code should explain code by being readable.

Comments are for whys. Why is the code doing the things it's doing. Why is the code doing this strange thing here. Why does a thing need to be in this order. Why do I need to store this value here.

Stuff like that.

[–] sugar_in_your_tea@sh.itjust.works 1 points 3 days ago* (last edited 3 days ago)

Better yet, a type hint. foo: list | None can be checked by static analysis, # foo is a list isn't.

[–] thebestaquaman@lemmy.world 1 points 3 days ago

There is no guarantee that the comment is kept up to date with the code. "Self documenting code" is a meme, but clearly written code is pretty much always preferable to unclear code with a comment, largely because you can actually be sure that the code does what it says it does.

Note: You still need to comment your code kids.

[–] iAvicenna@lemmy.world 0 points 4 days ago

If there is an alternative through which I can achieve the same intended effect and is a bit more safer (because it will verify that it has len implemented) I would prefer that to commenting. Also if I have to comment every len use of not that sounds quite redundant as len checks are very common