Thanks a lot @kristjanvalur. I always wanted to revisit this part of the code anyway. Will definitely look into this, but please have some patience since I'm currently busy with other things.

Also, I think it is prudent for you to review the semantics here. I see that this has recently been renamed to "Iterable" rather than "Iterator". I am not sure that this is wise. A list is an "iterable", but a list iterator is, while technically also an iterable, is an iterator. The concept of an iterable is something which can be iterated over multiple times.
In the sense of subscriptions, this makes no sense. (You don't want to execute the same subscription multiple times)
If something has a __next__() method, it is primarily an iterator. (same goes for async)

By the way, one of the bad side effects of the previous implementation is that it makes debugging hard. The __anext__() method is executed in its own Task which means that the call chain is broken.

Also, I think it is prudent for you to review the semantics here. I see that this has recently been renamed to "Iterable" rather than "Iterator". I am not sure that this is wise.

I was mirroring that change in Change.js here. I think JavaScript was inspired by Python regarding iterables, so the semantics is pretty similar. The reason for the renaming was that the class has an __aiter__ method. So it is not only an Iterator, but also an Iterable (similar for JavaScript).

Remember that the goal of GraphQL.js is to be a pretty much 1:1 translation of GraphQL.js to Python. I try to avoid doing or naming things differently, because only by staying close to the original it is sustainable to maintain the library and keep it up to date with the current developments.

For instance, I'm currently working on getting the @defer/@stream directives from GraphQL.js into GraphQL.core which is quite a big feature which requires many changes in the execution module. I will look into your PR once I'm done with that big change, and make sure it's compatible.

By the way, one of the bad side effects of the previous implementation is that it makes debugging hard. The __anext__() method is executed in its own Task which means that the call chain is broken.

Agreed, that's another good reason to change it.

Yes, no rush at all. I'll probably implement workarounds in strawberry anyway.

I also had time to think it over and I don't think my comments on iterables/iterators are necessarily correct, I guess I got caught up in the moment. Cheers!