Is the shortcircuit behaviour of Python's any/all explicit?

The behaviour is guaranteed. I've contributed a patch, which was accepted and merged recently, so if you grab the latest sources you will see that the short-circuiting behaviour is now explicitly enforced.

git clone https://github.com/python/cpython.gitgrep Short-circuit cpython/Lib/test/test_builtin.py

The docs say

"Return True if any element of the iterable is true. If the iterable is empty, return False. EQUIVALENT TO:" (emphasis mine) ...

def any(iterable):    for element in iterable:        if element:            return True    return False

If any didn't short circuit, it wouldn't be EQUIVALENT to the posted code since the posted code clearly short circuits. You could consume more of a generator than you want to for example. In light of that, I say that the short circuiting behavior is guaranteed.

The exact same argument could be made for all.

In case you landed here looking for "do any/all always always short-circuit?"

They do, but there is a gotcha: using a list comprehension can make it seem like you are overriding the short-circuiting behavior:

def hi():    print('hi')    return True>>> any(hi() for num in [1, 2, 3, 4])hi>>> any([hi() for num in [1, 2, 3, 4]])hihihihi

The list comprehension executes before any() does.

(Note: This does not answer the OP's very different question. This is the only stackoverflow page that comes up for me when searching "any all short circuit python.")