Does this still look like this generates multiple values?
result = [any value < 0 for value in range(stop)]
result = [each value >= 0 for value in range(stop)]
I don’t mind too much about the specific syntax, as long as it’s intuitive.
If you prefer consistency over grammar, this is also possible:
result = [any value < 0 for value in range(stop)]
result = [all value >= 0 for value in range(stop)]
Maybe it could even make sense without brackets? A bit like the type keyword.
result = any value < 0 for value in range(stop)
result = all value >= 0 for value in range(stop)
And if this is allowed too, we can just explain that brackets are now optional for all() & any(), leading to better performance.
result = any iterable
result = all iterable
I don’t want to give up on this proposal yet, we haven’t explored everything yet.
Correction: parentheses would be optional, not brackets.
OK, it’s a little more complicated:
result = all (1, 2, 3) # TypeError: all() takes exactly one argument (3 given)
result = all [1, 2, 3] # TypeError: 'builtin_function_or_method' object is not subscriptable
result = all {1, 2, 3} # SyntaxError: invalid syntax
Have you considered not changing the syntax at all but just having the interpreter recognize code like any(key in m for m in self.maps) and handle it differently if any turns out to be the built-in function?
Isn’t that only possible with the JIT compiler? It might be, but it feels like it would be even more work. And it’s not sure if it would even leave experimental phase before 3.13 reaches end of life.
Wasn’t this already brought up?
We’re not exploring anything here; it’s you who has to come up with a proposal and wait for feedback. It’s as simple as that.
Could you please move this thread to Help?
I found it:
I moved the thread to help.
No, it’d be possible without the JIT. In fact, that kind of special case would be unnecessary with the JIT, since the JIT accomplishes much the same thing, but in a more general way.
OK, if someone can implement that, I’m all aboard. Otherwise we need new syntax.
About that @pf_moore, I know you said you didn’t intend to get into further debate on this proposal, but does this look better to you? I’m just asking for your opinion.
We have the syntax already: the for loop. all() and any() are just built-in functions.
Creating new syntax just for the sake of speed doesn’t make sense at all.
Well, at the very least put a note in the docs then. I think people righfully expect that all(... for ... in ...) is as fast as a for loop.
After all it’s a builtin function. And I believe this applies to all(map()) & any(map()) as well.
If you’ve been using Python for years, you might have noticed that different syntax/functions yield different performance results in different Python versions.
Remember, Python isn’t primarily about speed; it’s about ease of use. Nonetheless, it’s fast enough for 99% of real-world use cases.
Whatever micro-optimizations you see merged in CPython, they may need to be reverted in the next version. I wouldn’t bother merging them at all.
Eh, only 5% of usage of all() & 9% of any() is efficient:
all(iterable) versus 3.2M for all(...)any(iterable) versus 1.8M for any(...)Therefore, I think this is definitely worth discussing.
You’re not just searching for the built-in all or any. Your search also includes user-defined all or any functions (or methods).
Furthermore, these numbers don’t matter much if these built-in functions aren’t being used in tight loops. They won’t significantly impact the performance of the application. That’s why they’re called micro-optimizations; their effects are negligible.
Rest assured, if performance is critical, users will resort to C extensions or even assembler.
It’s not simple to filter them out. And that actually strengthens my argument as it decreases the percentage.
I haven’t figured out how to call C code from a python repository downloaded straight from GitHub, so I currently need to optimise my Python code as well as I can.
Where it matters, not when I’m waiting for user input but when I’m doing heavy calculations.