The interpreter can’t make the replacement until it’s about to execute the line as __bool__ and __len__ are both (Python’s equivalent of) virtual functions, so it’s got to know the runtime type to know if the substitution is valid. Once it’s that late, it’ll often be faster to execute the requested function than work out if it could execute something faster instead. Even with type hints, it’s possible that a subclass with overridden methods could be passed in, so it’s not safe to do anything until the real runtime type is known.

Once there’s a JIT involved, there’s an opportunity to detect the common types passed to a function and call specialised implementations, but I don’t think Python’s JIT is clever enough for this. LuaJIT definitely does this kind of optimisation, though.

Even so, not x is a pretty nice-to-read pattern, and it’s nice that it’s faster than the less nice len(x) == 0. I generally do not care to distinguish whether a list is None or empty, I just want to know if there’s something there. If I care, then I’ll typically separate those checks anyway: if x is None: ..., if len(x) == 0: ....

len(mylist) tells me it’s definitely a list and not null or whatever

Do you know what else can tell you it’s a list? Type hinting.

If I care about the distinction between None and an empty list, I’ll make separate checks. len(None) raises an exception, and most of the time that’s not what I want when checking whether there’s something in the list, so not x is generally preferred, especially when type hinting is used consistently enough to be reasonably sure I’m actually getting a list or None. If I get something else, that means things got really broken and they’ll likely get an exception alter (i.e. when doing anything list-like).

For sequence type objects, such as lists, their truth value is False if they are empty.

That’s generally exactly what I want. len(x) == 0 doesn’t tell you it’s a list, it just tells you it has __len__. So that could be a dict, list, or a number of other types that have a length, but aren’t lists.

Don’t rely on checks like that to tell you what type a thing is.

“Many” isn’t the same as “most,” though I don’t think there’s any way to know what “most” is.

But here’s my reason for agreeing w/ the OP:

• not x checks both None and emptiness, which is usually desired
• len(x) == 0 will raise an exception if x is null
• with type hinting, those should be the only two reasonable options

It’s nice that it’s slightly faster, though performance has absolutely nothing to do w/ my preference, though it does have something to do with my preference for avoiding exceptions for non-exceptional cases.

Why? not x means x is None or len(x) == 0 for lists. len(x) == 0 will raise an exception if x is None. In most cases, the distinction between None and [] isn’t important, and if it is, I’d expect separate checks for those (again, for explicitness) since you’d presumably handle each case differently.

In short:

• if the distinction between None and [] is important, have separate checks
• if not, not x should be your default, since that way it’s a common pattern for all types

I never understood that argument. If you can be sure the type is a collection (and this you always should) not list is so moch easier to read and understood than the length check.

In complex cases where speed is less important than maintainability, I tend to agree.

In this case, a simple comment would suffice. And in fact nothing at all would be okay for any half-competent Python coder, as testing if lists are empty with if not is super-standard.

I’d argue that if it’s strict explicitness you want, python is the wrong language. if not var is a standard pattern in python. You would be making your code slower for no good reason.