cc @markshannon, @JelleZijlstra

I'll do the initial review on this later today. In the meantime, you can rebase against main to fix the JIT failures (see gh-126465).

For future reference, don't force push. Everything is squashed onto main anyway.

For future reference, don't force push. Everything is squashed onto main anyway.

I've used the Github button "rebase", it made force push.
But local merging with main and pushing to this branch is preffered, isn't it?

I like to use the "Update branch" button, which merges in main without a need for local actions. We try to avoid force-pushes since they make it harder to track the history of the PR.

I thought the idea was to entirely remove the GET_ITER, now that the generator expression handles the conversion from iterable to iterator.

I realize that would be a slight change, but it makes generator expressions behave the same as generators:

>>> def make_gen(x):
...     for i in x:
...         yield i
...
>>> gen = make_gen(1)  # No error here
>>> next(gen)
Traceback (most recent call last):
  File "<python-input-28>", line 1, in <module>
    next(gen)
    ~~~~^^^^^
  File "<python-input-26>", line 2, in make_gen
    for i in x:
             ^
TypeError: 'int' object is not iterable

Creating a generator with a non-iterable is fine. It is only we try to iterate over it, that an error occurs.

It's not possible to check arguments of an arbitrary generators, since it can be of any type.
For example, this generator is correct:

def make_range_gen(n, m):
    for i in range(n + m * 5):
        yield i

But generator expressions can have only one parameter, which should be Iterable.
So we can guarantee that argument is really Iterable.

Let's look at the solution with CHECK_ITERABLE bytecode.
Pros:

1. Backward compatibility in all details.
2. Early detection of incorrect code in genexprs.
3. Very small impact on perfomance, almost zero, since implementation of CHECK_ITERABLE is very simple.

Cons:

1. Small impact on memory size of compiled object (+2 bytes on each creation of genexpr).
2. New bytecode with little purpose, which uses one of byte values in range(256), and we want to keep those values for important bytecodes.

I'm not sure about the balance of this pros and cons for the typical user of Python.
Backward compatibility seems to be essential advantage.
But, of course, I can remove CHECK_ITERABLE, if you sure that solution without it is better.

@ZeroIntensity, @JelleZijlstra, what do you think?

Creating a generator with a non-iterable is fine. It is only we try to iterate over it, that an error occurs.

Can we please discuss this a bit more? I don't think that changing where the error happens is safe in terms of backward compatibility.

I am 100% sure that people expect error to happen when the gen is created and I am also sure that the code reflects that (validation, error handling, etc).

If we are going to break this - we need to issue a deprecation period.

I also don't fully understand why we are doing this.

It seems that this PR can be closed because other PR on this topic (#132351) is already merged.