• @[email protected]
    link
    fedilink
    English
    7914 days ago

    I write a lot of Python. I hate it when people use “X is more pythonic” as some kind of argument for what is a better solution to a problem. I also have a hang up with people acting like python has any form of type safety, instead of just embracing duck typing.This lands us at the following:

    The article states that “you can check a list for emptiness in two ways: if not mylist or if len(mylist) == 0”. Already here, a fundamental mistake has been made: You don’t know (and shouldn’t care) whether mylist is a list. These two checks are not different ways of doing the same thing, but two different checks altogether. The first checks whether the object is “falsey” and the second checks whether the object has a well defined length that is zero. These are two completely different checks, which often (but far from always) overlap. Embrace the duck type- type safe python is a myth.

    • @[email protected]
      link
      fedilink
      English
      8
      edit-2
      14 days ago

      isn’t the expected behaviour exactly identical on any object that has len defined:

      “By default, an object is considered true unless its class defines either a bool() method that returns False or a len() method that returns zero, when called with the object.”

      ps: well your objection is I guess that we cant know in advance if that said object has len defined such as being a collection so this question does not really apply to your post I guess.

      • @[email protected]
        link
        fedilink
        English
        714 days ago

        It’s not the same, and you kinda answered your own question with that quote. Consider what happens when an object defines both dunder bool and dunder len. It’s possible for dunder len to return 0 while dunder bool returns True, in which case the falsy-ness of the instance would not depend at all on the value of len

      • @[email protected]
        link
        fedilink
        English
        314 days ago

        Exactly as you said yourself: Checking falsieness does not guarantee that the object has a length. There is considerable overlap between the two, and if it turns out that this check is a performance bottleneck (which I have a hard time imagining) it can be appropriate to check for falsieness instead of zero length. But in that case, don’t be surprised if you suddenly get an obscure bug because of some custom object not behaving the way you assumed it would.

        I guess my primary point is that we should be checking for what we actually care about, because that makes intent clear and reduces the chance for obscure bugs.

    • @[email protected]
      link
      fedilink
      English
      113 days ago

      type safe python is a myth

      Sure, but type hints provide a ton of value in documenting for your users what the code expects. I use type hints everywhere, and it’s fantastic! Yes, there’s no guarantee that the types are correct, but with static analysis and the assumption that your users want their code to work correctly, there’s a very high chance that the types are correct.

      That said, I lie about types all the time. For example, if my function accepts a class instance as an argument, the intention is that the code accept any class that implements the same methods as the one I’ve defined in the parameter list, and you don’t necessarily have to pass an instance of that class in (or one of its sub-classes). But I feel like putting something reasonable in there makes a lot more sense than nothing, and I can clarify in the docstring that I really just need something that looks like that object. One of these days I’ll get around to switching that to Protocol classes to reduce type errors.

      That said, I don’t type hint everything. A lot of private methods and private functions don’t have types, because they’re usually short and aren’t used outside the class/file anyway, so what’s the point?

      • @[email protected]
        link
        fedilink
        English
        113 days ago

        Type hints are usually great, as long as they’re kept up to date and the IDE interprets them correctly. Recently I’ve had some problems with PyCharm acting up and insisting that matplotlib doesn’t accept numpy arrays, leading me to just disable the type checker altogether.

        All in all, I’m a bit divided on type hints, because I’m unsure whether I think the (huge) value added from correct type hints outweighs the frustration I’ve experienced from incorrect type hints. Per now I’m leaning towards “type hints are good, as long as you never blindly trust them and only treat them as a coarse indicator of what some dev thought at some point.”

        • @[email protected]
          link
          fedilink
          English
          113 days ago

          leading me to just disable the type checker altogether.

          The better option is to just put # type: ignore on the statements where it gets confused, and add hints for your code. I’ve done that for SQLAlchemy before they got proper type hinting, and it worked pretty well.

          That said, a type hint is just that, a hint. It shouldn’t be relied on to be 100% accurate (i.e. lots of foo: list should actually be foo: list | None), but if you use a decent static analysis tool, you should catch the worst of it. We use pyright, which is built in to the VSCode extension pylance. It works incredibly well, though it’s a bit too strict in many cases (e.g. when things can be None but generally aren’t).

          So yeah, never blindly trust type hints, but do use them everywhere. The more hints you have, the more the static analysis can help, and disabling them on a case-by-case basis is incredibly easy. You’ll probably still get some runtime exceptions that correct type checking could have caught, but it’s a lot better than having a bunch of verbose checks everywhere that make no sense. A good companion to type checks is robust unit test cases with reasonable data (i.e. try to exercise the boundaries of what users can input).

          As it stands, we very rarely get runtime exceptions due to poor typing because our type hints are generally pretty good and our unit test cases back that up. Don’t blindly trust it, and absolutely read the docs for anything you plan to use, but as long as you are pretty consistent, you can start making some assumptions about what your data looks like.

          • @[email protected]
            link
            fedilink
            English
            0
            edit-2
            13 days ago

            I really do agree on all your points, so at the end of the day I think a lot comes down to use-case and personal preference.

            My primary use cases for Python are prototyping and as a frontend/scripting tool for software written in C/C++/Fortran. In those scenarios, spending significant time on type hinting and unittests defeats the purpose of using Python (blazing fast development).

            I’ve written/worked on only one larger code base in pure Python, and my personal opinion became that I heavily prefer strictly typed languages once the code base exceeds a certain size. It just feels so much smoother to work with when I have actual guarantees that are enforced by the language.

            With that said, we were a bunch of people that are used to using Python for prototyping that developed this larger library, and it would probably have gone a lot better if we actually enforced use of proper type hinting from the start (which we were not used to).

            • @[email protected]
              link
              fedilink
              English
              013 days ago

              I heavily prefer strictly typed languages once the code base exceeds a certain size

              As do I, but we don’t all get to pick our stack.

              I use Rust for all my personal projects unless I have a good reason to pick something else. I like pretty much everything about it, from the lack of classes (I hate massive class hierarchies) to the borrow checker to everything being an expression. It feels like I’m getting most of the benefits of functional programming, without being tied down to FP to solve problems.

              That said, I think Python is a reasonable choice for large codebases. For simple scripts, I generally don’t bother with type hints. At my current company, our largest codebase is well over 100k lines of Python, so the type hints are absolutely welcome since they help document code I haven’t touched in over a year (if ever). If things get slow, there’s always the option of a native module. But for most things, Python is fast enough, so it’s no big deal. Because of this, I use type hints for anything that might become a larger project. After the initial POC, I’ll go through and update types, fix a bunch of linting warnings/errors, and flesh out the unit tests. That way I have something to build from when I inevitably come back to it in a year or so.

              So yeah, I definitely recommend using type hinting. The best time to add type hints is at the start of development, the next best time is now.

              • @[email protected]
                link
                fedilink
                English
                113 days ago

                The next best time is now

                If my Easter break gets boring I might just start cleaning up that Python library… It’s the prime example of something that developed from a POC to a fully functional code base, was left largely unused for about a year, and just the past weeks has suddenly seen a lot of use again. Luckily we’re strict about good docstrings, but type hints would have been nice too.

                • @[email protected]
                  link
                  fedilink
                  English
                  113 days ago

                  Woo, do it! And add some tests while you’re at it in case those don’t exist.

                  I found a few bugs just going through and cleaning up missing code coverage. Maybe you’ll find the same!

  • Sirber
    link
    fedilink
    English
    34
    edit-2
    14 days ago

    How does Python know if it’s my list or not?

    • @[email protected]
      link
      fedilink
      English
      614 days ago

      if isinstance(mylist, list) and not mylist

      Problem solved.

      Or if not mylist # check if list is empty

      • @[email protected]
        link
        fedilink
        English
        314 days ago

        You’re checking if mylist is falsey. Sometimes that’s the same as checking if it’s empty, if it’s actually a list, but that’s not guaranteed.

        • @[email protected]
          link
          fedilink
          English
          114 days ago

          Doesn’t Python treat all empty iterables as false tho? This isn’t unique to python, is it? (though I’m not a programmer…just a dude who writes scripts every now and then)

          • @[email protected]
            link
            fedilink
            English
            314 days ago

            My point is that the second statement you presented can have the effect of evaluating emptiness of a Sequence (note: distinct from an Iterable), but that only holds true if the target of the conditional IS a sequence. I’m underlining the semantic difference that was elided as a result of falsey evaluation.

          • @[email protected]
            link
            fedilink
            English
            214 days ago

            Not really, generators have weird truthiness, i don’t remember if they evaluate to true or false, but they cannot be checked for emptiness so they default to either always true or always false.

  • @[email protected]
    link
    fedilink
    English
    3014 days ago

    I know I’m gonna get downvoted to oblivion for this, but… Serious question: why use Python if you’re concerned about performance?

    • @[email protected]
      link
      fedilink
      English
      3814 days ago

      It’s all about trade-offs. Here are a few reasons why one might care about performance in their Python code:

      1. Performance is often more tied to the code than to the interpreter - an O(n³) algorithm in blazing fast C won’t necessarily perform any better than an O(nlogn) algorithm in Python.
      2. Just because this particular Python code isn’t particularly performance constrained doesn’t mean you’re okay with it taking twice as long.
      3. Rewriting a large code base can be very expensive and error-prone. Converting small, very performance-sensitive parts of the code to a compiled language while keeping the bulk of the business logic in Python is often a much better value proposition.

      These are also performance benefits one can get essentially for free with linter rules.

      Anecdotally: in my final year of university I took a computational physics class. Many of my classmates wrote their simulations in C or C++. I would rotate between Matlab, Octave and Python. During one of our labs where we wrote particle simulations, I wrote and ran Octave and Python simulations in the time it took my classmates to write their C/C++ versions, and the two fastest simulations in the class were my Octave and Python ones, respectively. (The professor’s own sim came in third place). The overhead my classmates had dealing with poorly optimised code that caused constant cache misses was far greater than the interpreter overhead in my code (though at the time I don’t think I could have explained why their code was so slow compared to mine).

      • @[email protected]
        link
        fedilink
        English
        414 days ago

        I appreciate the large amount of info. Great answer. It just doesn’t make sense to me, all things being equal (including performant algorithms), why choose Python and then make a small performance tweak like in the article? I understand preferring the faster implementation, but it seems to me like waxing your car to reduce wind resistance to make it go faster, when installing a turbo-charger would be much more effective.

        • @[email protected]
          link
          fedilink
          English
          714 days ago

          If you use the profiler and see that the slower operation is being used frequently, and is taking up a chunk of time deemed significant, why not swap it to the faster version?

          In a simulation I’m working on that goes through 42 million rounds I spent some time profiling and going through the code that was eating up a lot of time (especially things executed all 42 million times) and trying to find some optimizations. Brought the run time down from about 10 minutes to 5 minutes.

          I certainly wasn’t going to start over in C++ or Rust, and if I’d started with either of those languages I would have missed out on a lot of really strong Python libraries and probably spent more time coding rather than refining the simulation.

        • @[email protected]
          link
          fedilink
          English
          414 days ago

          I think a better analogy would be that you’re tuning your bike for better performance because the trade-offs of switching to a car are worse than keeping the bike.

      • @[email protected]
        link
        fedilink
        English
        0
        edit-2
        14 days ago
        1. Performance is often more tied to the code than to the interpreter - an O(n³) algorithm in blazing fast C won’t necessarily perform any better than an O(nlogn) algorithm in Python.

        An O(n³) algorithm in Python won’t necessarily perform any better than an O(nlogn) algorithm in C. Ever heard of galactic algorithms?

        The overhead my classmates had dealing with poorly optimised code that caused constant cache misses was far greater than the interpreter overhead in my code (though at the time I don’t think I could have explained why their code was so slow compared to mine).

        Did they write naive linear algebra operators?

    • @[email protected]
      link
      fedilink
      English
      814 days ago

      You may want to beneficiate from little performance boost even though you mostly don’t need it and still need python’s advantages. Being interested in performance isnt always looking for the very best performance there is out of any language, it can also be using little tips to go a tiny bit faster when you can.

    • @[email protected]
      link
      fedilink
      English
      114 days ago

      I have the same question. I prefer other languages. I use G’MIC for image processing over Python and C++.

    • Jerkface (any/all)
      link
      fedilink
      English
      114 days ago

      Alternatively, why wait twice as long for your python code to execute as you have to?

    • @[email protected]
      link
      fedilink
      English
      113 days ago

      It comes down to the question “Is YOUR C++ code faster than Python?” (and of course the reverse).

      I’ve built a SCADA from scratch and performance requirements are low to begin with, seeing as it’s all network bound and real world objects take time to react, but I’m finding everything is very timely.

      A colleague used SQLAlchemy for a similar task and got abysmal performance. No wonder, it’s constantly querying the DB for single results.

      • @[email protected]
        link
        fedilink
        English
        113 days ago

        Exactly!

        We rewrote some Fortran code (known for fast perf) into Python and the net result was faster. Why? They used bubble sort in a hot loop, whereas we used Python’s built-in sort (probably qsort or similar). So despite Python being “slower” on average, good architecture matters a lot more.

        And your Python code doesn’t have to be 100% Python, you can write performance-critical code in something else, like C++ or Rust. This is very common, and it’s why popular Python libraries like numpy and scipy are written in a more performant language with a Python wrapper.

    • @[email protected]
      link
      fedilink
      English
      1
      edit-2
      13 days ago

      Honestly most people use Python because it has fantastic libraries. They optimize it because the language is middling, but the libraries are gorgeous

      ETA: This might double post because my Internet sucks right now, will fix when I have a chance

        • @[email protected]
          link
          fedilink
          English
          013 days ago

          What do I care what language the library is written in as long as it works for what I need it do?

          • @[email protected]
            link
            fedilink
            English
            113 days ago

            Exactly! Most of the important libraries in other languages have Python support. So I can use Python and not care if they wrote the library in C++, Rust, or something more exotic, provided it works in Python.

            Python is more about gluing stuff together than writing a bunch of greenfield logic. If you run into performance problems and you’re using Python, the best solution is to start rewriting the slow parts in something faster, not to rewrite the whole thing in something different.

            That said, most of my personal projects are in Rust, for a variety of reasons. But I still use a lot of Python as well, and it’s what I use 99% of the time at work.

    • @[email protected]
      link
      fedilink
      English
      1
      edit-2
      13 days ago

      Yes, Python is the wrong choice if performance is your top priority.

      But here’s another perspective: why leave easy performance wins on the table? Especially if the cost is simpler code that works as you probably wanted anyway with both None and []?

      Python is great if you want a really fast development cycle, because the code is generally quite simple and it’s “fast enough.” Any wins for “fast enough” is appreciated, because it delays me needing to actually look into little performance issues. It’s pretty easy for me to write a simple regex to fix this cose (s/if len\((\w+)\) == 0:/if not \1:/), and my codebase will be slightly faster. That’s awesome! I could even write up a quick pylint or ruff rule to catch these cases for developers going forward (if there isn’t one already).

      If I’m actively tweaking things in my Python code to get a little better performance, you’re right, I should probably just use something else (writing a native module is probably a better use of time). But the author isn’t arguing that you should do that, just that, in this case, if not foo is preferred over if len(foo) == 0 for technical reasons, and I’ll add that it makes a ton of sense for readability reasons as well.

      Here are some other simple wins:

      • [] and {} instead of list() and dict() - the former copy constants, whereas the latter actually constructs things; oh, and you save a few chars
      • use list comprehensions instead of regular loops - list comprehensions seem to be faster due to not needing to call append (and less code)
      • use built-ins when you can - they’re often implemented in native code

      I consider each of those cleaner Python code anyway, because they’re less code, just as explicit, and use built-in language features instead of reinventing the wheel.

    • @[email protected]
      link
      fedilink
      English
      0
      edit-2
      13 days ago

      This is my two cents as someone in the industry.

      Because, while you don’t want to nitpick on each instruction cycle, sometimes the code runs millions of times and each microsecond adds up.

      Keep in mind that people use this kind of things for work, serving real world customers who are doing their work.

      Yes, the language itself is not optimal even by design, but its easy to work with, so they are making it worth a while. There’s no shortage of people who can work with it. It is easy to develop and maintain stuff with it, cutting development cost. Yes, we’re talking real businesses with real resource constraints.

      • @[email protected]
        link
        fedilink
        English
        013 days ago

        Exactly. We picked it for the reasons you mentioned, and I still think it’s a good choice.

        That said, some of our heavier logic is in a lower-level language. We had some Fortran code until recently (rewrote in Python and just ate the perf cost to lower barrier to other devs fixing stuff), and we’re introducing some C++ code in the next month or two. But the bulk of our code is in Python, because that’s what glues everything together, and the code is fast enough for our needs.

        • @[email protected]
          link
          fedilink
          English
          212 days ago

          People seem to be unaware that python has bindings for lower-level languages like C. In fact, people have been heavily using resource intensive libraries implemented in C (e.g. numpy, scipy, pandas, uwsgi).

          Also, Python interpreter performance has come a long way.

  • @[email protected]
    link
    fedilink
    English
    19
    edit-2
    14 days ago

    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.

      • @[email protected]
        link
        fedilink
        English
        514 days ago

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

      • @[email protected]
        link
        fedilink
        English
        314 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

        • @[email protected]
          link
          fedilink
          English
          714 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.

          • @[email protected]
            link
            fedilink
            English
            4
            edit-2
            14 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 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 (any/all)
              link
              fedilink
              English
              3
              edit-2
              14 days ago

              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.

              • @[email protected]
                link
                fedilink
                English
                214 days ago

                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 (any/all)
                  link
                  fedilink
                  English
                  1
                  edit-2
                  14 days ago

                  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.

            • @[email protected]
              link
              fedilink
              English
              114 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.

              • @[email protected]
                link
                fedilink
                English
                114 days ago

                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?

          • @[email protected]
            link
            fedilink
            English
            214 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).

          • @[email protected]
            link
            fedilink
            English
            314 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.

      • @[email protected]
        link
        fedilink
        English
        1
        edit-2
        14 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?

      • @[email protected]
        link
        fedilink
        English
        114 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.

      • @[email protected]
        link
        fedilink
        English
        014 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

  • @[email protected]
    link
    fedilink
    English
    714 days ago

    Could also compare against:

    if not len(mylist)
    

    That way this version isn’t evaluating two functions. The bool evaluation of an integer is false when zero, otherwise true.

    • @[email protected]
      link
      fedilink
      English
      214 days ago

      This is honestly the worst version regarding readability. Don’t rely on implicit coercion, people.

      • @[email protected]
        link
        fedilink
        English
        114 days ago

        But the first example does the same thing for an empty list. I guess the lesson is that if you’re measuring the speed of arbitrary stylistic syntax choices, maybe Python isn’t the best language for you.

  • @[email protected]
    link
    fedilink
    English
    414 days ago

    There are decades of articles on c++ optimizations, that say “use empty() instead of size()”, which is same as here.

  • palordrolap
    link
    fedilink
    314 days ago

    As a Perl fossil I recognise this syntax as equivalent to if(not @myarray) which does the same thing. And here I was thinking Guido had deliberately aimed to avoid Perlisms in Python.

    That said, the Perlism in question is the right* way to do it in Perl. The length operator does not do the expected thing on an array variable. (You get the length of the stringified length of the array. And a warning if those are enabled.)

    * You can start a fight with modern Perl hackers with whether unless(@myarray) is better or just plain wrong, even if it works and is equivalent.

    • tiredofsametab
      link
      fedilink
      114 days ago

      I really liked unless in perl; especially as I get older !length or something makes that bang really easy to miss. I use !(length) or something instead to visually set it aside. unless made this much more visually clear.

    • @[email protected]
      link
      fedilink
      English
      114 days ago

      Empty sequences being false goes back a lot further than perl, it was already a thing in the first lisp (in fact the empty list was the cannonical false).

    • @[email protected]
      link
      fedilink
      English
      113 days ago

      Looks like it. It’s a complete fever dream graph. I really don’t get how someone can use an image like that. Personally I don’t really like AI art anyways, but I could somewhat understand it as a sort of “filler” image to make your article a bit more interesting. But a graph that is supposed to convey actual information? No idea why anyone would AI gen that without checking

    • @[email protected]
      link
      fedilink
      English
      113 days ago

      I think there’s a good chance of that:

      • -2x instead of ~2x - a human is unlikely to make that mistake
      • no space here: ==0 - there’s a space every other time it’s done, including the screenshot
      • the numbers are wrong - the screenshot has different data than the image
      • why are there three bars? A naive approach would have two.
  • @[email protected]
    link
    fedilink
    English
    2
    edit-2
    12 days ago

    From that little image, they’re happy it takes a tenth of a fucking second to check if a list is empty?

    What kind of dorito chip is that code even running on?

  • @[email protected]
    link
    fedilink
    English
    113 days ago

    I could have tripped, knocked over my keyboard, cried for 13 straight minutes on the floor, picked my keyboard back up, accidentally hit the enter key making a graph and it would have made more sense than this thing.

    -2x faster. What does that even mean?

    • @[email protected]
      link
      fedilink
      English
      013 days ago

      You’d need to explicitly check for None if using the len() construct as well, so this doesn’t change the point of the article.

      • @[email protected]
        link
        fedilink
        English
        1
        edit-2
        13 days ago

        But None has no len

        if not foo:  
        

        -> foo could be an empty list or None, it is ambiguous.

        len(foo) will lead to an exception TypeError if foo is None, I can cleanly catch that.

        It suggests I deal with a boolean when that is not the case. Explicit is better than implicit, and if not foo to check for an empty list may be pythonic, but it’s still implicit af

        • @[email protected]
          link
          fedilink
          English
          013 days ago

          My point is that if your variable can be None then you need the same pattern for the length check.

          So for the Pythonic version:

          if (foo is not None) and not foo:
             ...
          

          For the explicit length check:

          if (foo is not None) and (len(foo) == 0):
            ...
          

          Honestly you’re probably better off using type hints and catching such things with static checks and not adding the None check.

          • @[email protected]
            link
            fedilink
            English
            1
            edit-2
            13 days ago

            This is what I would come up with:

            try:
                if len(foo) == 0:
                ...
            except TypeError:
                ...
            

            There is no need to add a None check, as foo being None should be considered as a faulty input. Avoiding the possibility of foo being None from the beginning using static checks or testing is of course the preferred solution. But in reality we do not work in such optimal environments, at least I can say that from the perspective of data science, where often procedural, untested code is produced that runs only a few times. But I get your point and I think both paths are viable, but I am also okay with being in the wrong here,