I see the value of having `aiter` and `anext` in the standard library, mostly because we should not encourage people to call dunder methods themselves unless they are doing something really tricky.
Also, if written in C, those functions may save the attribute fetch overhead of a method call for asynchronous iterables and iterators written with the Python/C API.
My feeling is `aiter` and `anext` should go in the operator module, where we already have lots of functions that are thin wrappers around dunder methods.
I think the builtin module is already overcrowded. Not advocating to remove anything, just saying we should think very carefully about adding two more functions to it.
Cheers,
Luciano
PS. I do think it was a good idea to remove `reduce` from the builtins in Python 3, as it was often used to do what `sum`, `all`, and `any` do more easily and efficiently.
I assume that one of the concerns is that these functions are trivial. aiter(x) is just x.__aiter__(), and anext(it) is just it.__next__(). I’m not convinced that we need aiter(x, sentinel) at all — for iter() it’s mostly a legacy compatibility API.
If you use these a lot it’s simple enough to add one-liners to the top of your module or to your project’s utilities.
I also feel (but I may be alone in this) that maybe we went overboard with the design of async for (and async with).
That said the work itself is impeccable. While you’re waiting for a resolution you may want to try working on other contributions!
—Guido
OK, but it seems clear to me that if there are any lingering doubts it would be better to add the functions to a module than to the built-ins, and later promote them to built-ins if people actually find them widely useful.
On the other hand, adding something to built-ins that turns out to be rarely useful adds unnecessary noise and is much harder to fix later without causing further problems.
Best,
Luciano
Thanks for taking a look at this, Luciano.
> Do these really need to be builtins?
We're only beginning to see async iterators being used in the wild, so we can't have a definitive answer at this point.
> They seem too specialized to be widely useful; I've personally never needed them in any async code I've written. It would make more sense to me to put them in a module like operators.
I think putting them to the operators module makes sense, at least for 3.8. Do you want to work on a pull request?
Please don't merge this yet. I'm not convinced that aiter and anext shouldn't be builtins.
So there has been some back-and-forth on this, and some more years have passed, but all the latest signals we've gotten up to now have indicated a preference for adding these to builtins.
In any case, as of
my latest PR, the Python core developers now have both options to choose from.
As community contributors, is there anything further we can do to help drive timely resolution on this one way or another?
Thanks,
Josh
Thanks for working on this, Joshua. I agree 100% with Jelle Zijlstra in the issue tracker:
Do these really need to be builtins?
They seem too specialized to be widely useful; I've personally never needed them in any async code I've written. It would make more sense to me to put them in a module like operators.
(sorry for the weird formatting, posting from an iPad)
--
--
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/R3I7WIXNZNVA534XFABDQJRHHKRB6X2S/
Code of Conduct: http://python.org/psf/codeofconduct/
--Guido (mobile)