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 On Fri, Mar 19, 2021 at 09:59 Luciano Ramalho <luci...@ramalho.org> wrote: > 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 > > > On Fri, Mar 19, 2021 at 1:22 PM Joshua Bronson <jabron...@gmail.com> > wrote: > >> Thanks for taking a look at this, Luciano. >> >> Yury immediately replied <https://bugs.python.org/issue31861#msg319520> >> to the comment from Jelle that you quoted with the following: >> >> > 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? >> >> >> >> That was on 2018-06-14. On 2018-08-24, I submitted >> https://github.com/python/cpython/pull/8895, "Add operator.aiter and >> operator.anext". On 2018-09-07, Yury left the following comment >> <https://github.com/python/cpython/pull/8895#pullrequestreview-153441599> >> on that PR: >> >> 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 >> <https://github.com/python/cpython/pull/23847>, 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 >> >> >> On Fri, Mar 19, 2021 at 11:29 AM Luciano Ramalho <luci...@ramalho.org> >> wrote: >> >>> 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) >>> >>> On Wed, Mar 17, 2021 at 21:01 Joshua Bronson <jabron...@gmail.com> >>> wrote: >>> >>>> Dear python-dev, >>>> >>>> New here (but not to Python). 👋 Brett Cannon recommended I start a >>>> thread here (thanks, Brett!). >>>> >>>> In December, two colleagues and I submitted >>>> https://github.com/python/cpython/pull/23847, "Add aiter and anext to >>>> builtins", which would fix https://bugs.python.org/issue31861. >>>> >>>> Would any core developers who may be reading this be willing and able >>>> to provide a code review? >>>> >>>> We would love to try to address any review feedback before having to >>>> fix (another round of) merge conflicts. (And ideally maybe even get this >>>> landed in time for the 3.10 feature freeze in early May?) >>>> >>>> Thanks and hope this finds you well. >>>> _______________________________________________ >>>> Python-Dev mailing list -- python-dev@python.org >>>> To unsubscribe send an email to python-dev-le...@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/5XUVPB5H4PFUGTC5F7KAN4STKAEOFBQM/ >>>> Code of Conduct: http://python.org/psf/codeofconduct/ >>>> >>> -- >>> Luciano Ramalho >>> | Author of Fluent Python (O'Reilly, 2015) >>> | http://shop.oreilly.com/product/0636920032519.do >>> | Technical Principal at ThoughtWorks >>> | Twitter: @ramalhoorg >>> >> > > -- > Luciano Ramalho > | Author of Fluent Python (O'Reilly, 2015) > | http://shop.oreilly.com/product/0636920032519.do > | Technical Principal at ThoughtWorks > | Twitter: @ramalhoorg > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@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)
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@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/4JLY7U6DGTHUR2JF7QZZSBZMEXTD6GPL/ Code of Conduct: http://python.org/psf/codeofconduct/
