Comment on Python Performance: Why 'if not list' is 2x Faster Than Using len()

• taladar@sh.itjust.works ⁨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

  source
• iAvicenna@lemmy.world ⁨4⁩ ⁨days⁩ ago

  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

  source

  • thebestaquaman@lemmy.world ⁨4⁩ ⁨days⁩ ago

    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.

    source

    • iAvicenna@lemmy.world ⁨4⁩ ⁨days⁩ ago

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

      source

      • jerkface@lemmy.ca ⁨4⁩ ⁨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.

        source

        • -> View More Comments
      • thebestaquaman@lemmy.world ⁨3⁩ ⁨days⁩ ago

        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.

        source

        • -> View More Comments
    • Glitchvid@lemmy.world ⁨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).

      source
  • catloaf@lemm.ee ⁨4⁩ ⁨days⁩ ago

    You can make that assumption at your own peril.

    source

    • WhyJiffie@sh.itjust.works ⁨4⁩ ⁨days⁩ ago

      I don’t think they are a minority

      source
    • iAvicenna@lemmy.world ⁨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.

      source
  • jerkface@lemmy.ca ⁨4⁩ ⁨days⁩ ago

    The main thing not is for is coercing a truthy value into an actual bool.

    source
• acosmichippo@lemmy.world ⁨3⁩ ⁨days⁩ ago

  i haven’t programmed since college 15 years ago and even i know that 0 == false.

  source
• jj4211@lemmy.world ⁨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.

  source
• sugar_in_your_tea@sh.itjust.works ⁨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:
  

  source
• JustAnotherKay@lemmy.world ⁨3⁩ ⁨days⁩ ago

  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

  source

  • sugar_in_your_tea@sh.itjust.works ⁨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
        ...
    

    source