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?
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.
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.
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?
It coerces any value into a bool, which can be a very helpful side effect.
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.
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.