Discover why 'if not mylist' is twice as fast as 'len(mylist) == 0' by examining CPython's VM instructions and object memory access patterns.
      • @[email protected]
        3•5 days ago

        def some_func(*args, kwarg=[])

        Don’t do this:

        def fun(l=[]):
    l.append(len(l))
    return l

fun()  # [0]
fun()  # [0, 1]
fun(l=[])  # [0]
fun()  # [0, 1, 2]
fun(l=None)  # raise AttributeError or TypeError if len(l) comes first

        This can be downright cryptic if you’re passing things dynamically, such as:

        def caller(*args, **kwargs):
    fun(*args, **kwargs)

        It’s much safer to do a simple check at the beginning:

        if not l: 
    l = []
          • @[email protected]
            2•5 days ago

            Then make it explicit:

            if l is None:
    raise ValueError("Must provide a valid value for...")

            Having an attribute or type error rarely provides the right amount of context to immediately recognize the error, especially if it’s deep inside the application. A lot of our old code makes stupid errors like TypeError: operator - not defined on types NoneType and float, because someone screwed up somewhere and wasn’t strict on checks. Don’t reply on implicit exceptions, explicitly raise them so you can add context, because sometimes stacktraces get lost and all you have is the error message.

            But in my experience, the practical difference between [] and None is essentially zero, except in a few cases, and those should stand out. I have a few places with logic like this:

            if l is None:
    raise MyCustomInvalidException("Must provide a list")
if not l: 
    # nothing to do
    return

            For example, if I make a task runner, an empty list could validly mean no arguments, while a null list means the caller screwed up somewhere and probably forgot to provide them.

            Explicit is better than implicit, and simple is better than complex.

          • @[email protected]
            2•4 days ago

            Oh no a stray None! Take cover …

            Robust codebase should never fail from a stray None

            Chaos testing is specifically geared towards bullet proofing code against unexpected param types including None.

            The only exception is for private support function for type specific checking functions. Where it’s obviously only for one type ever.

            We live in clownworld, i’m a clown and keep the company of shit throwing monkeys.

              • @[email protected]
                1•20 hours ago

                type hints are static, not necessarily runtime.

                A chaos monkey throws everything at everything to see what breaks.

                That won’t be caught by perfect type hints, which is merely one tool in the toolbox.

                and when things break, often hear WAD, works as designed. Or some other nonsense excuse.