not if it can't solve the problem in the first place.
use this test case:
" A stitch in time saves nothing"

Use spoiler flag, please.

nmadsen, that is not true: all will return as soon as it hits a false value. And this will happen at the same entry as the not any variant, since the expression is opposite.

From a logical standpoint, you are correct. However, not any() is faster than all() in this case for any non-prime number because any() will return true as soon as it hits a true value (i.e. it doesn't have to go through the whole range) whereas all() has to check the entire range before outputting its result.

not any = all not

@hfaran: I have no idea why they should be. If eta-reduction works in Python the same way it works in other languages, both variants should be the same.

I'll bite. Why, indeed, is wrapping it in a lambda any better or more valid?

Indeed, it is easy to write, but with larger lists it coul fail. I guess it goes well for a 7 kyu kata, but if there was some time or other resource constraint on a large list, it would suffer from it.

What's the magic behind?

That's right. But neither Python nor the majority of other languages in Codewars are really meant for super efficient calculations; they are meant for writing code in a "programmer-friendly" way. That's what I'm doing here, taking advantage of the fact that str calculates a number's digits for free. Furthermore, if you insist on talking about efficiency, the alternative being a loop that calculates and sums digits using divmod, this solution is only slower by a constant factor; they are both O(logN).