For any & every

[Nineteendo (Nice Zombies)]

@dg-pb

If going in this direction, then I think eliminating counting example from your examples would make things simpler for now.

What do you mean? I’m not counting anything.

---

@MegaIng

Or will this syntax be special cased so much that the generator object isn’t even created?

It’s no syntax, but it will be special cased. Calling it on a regular generator still works.

---

@MegaIng

I see a lot of confusion being caused by any(...) vs (...).any() in the future. It also reads even worse, and hides a potential important aspect of the expression at the end of it.

I don’t like that either, but it’s difficult to do this without adding new syntax or keywords.

---

@MegaIng

I would much prefer introducing the ability for the bytecode compiler to special case builtins in general

Sounds interesting, sadly that probably requires a __future__ import, which can’t be used in older code:

try:
    from __future__ import some_awesome_new_feature
except:
    pass
# SyntaxError: from __future__ imports must occur at the beginning of the file

[dg-pb]

I take back half of what I said.

@MegaIng

Or will this rely on JIT to have a performance benefit?

How would that work?

@Nineteendo

What do you mean? I’m not counting anything.

My mistake, I took your Example 3 for something other than it is. By the way, it will always evaluate to False. Something more realistic would be better in its place.

Is there no other way to achieve optimization your are aiming at without new syntax introduction?

[Nineteendo (Nice Zombies)]

@dg-pb

Something more realistic would be better in its place.

Updated:

result = (value < 0 for values in values_list if len(values) > 5
                    for value in values).any()

---

@dg-pb

Is there no other way to achieve optimization your are aiming at without new syntax introduction?

Again, it’s no new syntax, just a method on a literal. I don’t see a way for them to even match the performance of a for loop if they’re builtins.