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.

[–] [email protected] 1 points 16 hours ago* (last edited 16 hours ago)

Hm... I'll admit I wasn't awkward of the .__len__ function. ~~However, does this mean it's possible to write a len(x) == 0 that's diverges from not x?~~

~~If not, then the substitution is still valid (and not presumably also considers the same fundamental. If so, that's kind of silly.~~

EDIT: I missed the part of your comment about .__bool__ ... so yeah in theory you could have something where these two operations are not equivalent.

Arguably, you could just say that's pathological and invalid. Then, still have an optimized path to prefer not .__bool__() if .__len__() == 0 is the comparison you'd be making. Even with the extra interpreter check during evaluation, that would quite possibly be faster if the overhead is truly high.

EDIT 2: you'd probably need a little bit more overhead than a straight substitution anyways because you need to maintain the semantic of "if this thing is None it's not valid if the syntax was originally len(x)."