Refactor len(...) == 0 to not ...

[brettcannon]

See https://snarky.ca/unravelling-not-in-python/ as to how this is equivalent to checking for the length of a container. It is also potentially faster as it avoids the container potentially having to calculate the length and creating the integer compared to returning a singleton.

[charliermarsh]

Am I correct that this could return a different result for a pathological class? E.g.:

class Foo:
    def __bool__(self):
        return False

    def __len__(self):
        return 1


foo = Foo()
print(not foo)
print(len(foo) == 0)

(I'm supportive of adding the rule and the fix -- just trying to understand when we can / can't guarantee that it's a safe transform.)

[brettcannon]

Correct, that pathological case would result in a different situation. But I would also say that's a bug since containers are not meant to be false-y when they are not empty. This is why a lack of __bool__ leads to a fallback to __len__: https://docs.python.org/3/reference/datamodel.html?highlight=__bool_#object.__bool__ .

[charliermarsh]

Cool, thank you, that makes sense. Consider my question reading comprehension from the blog post :)

[karelvaculik]

I believe some people might use such an transformation, but I can imagine scenarios where it fails quickly. For example, create a function that works with both lists and numpy arrays (like in sklearn). You might be able to call not my_list, but calling not my_array will raise an exception.