Okay, after looking at the operator module a bit more I agree with Yury -- we should make these builtins. Note that there's nothing for __iter__ and __next__ in operator, so adding things for __aiter__ and __anext__ would still be inconsistent. But adding them as builtin is consistent with the builtins for __iter__ and __next__.
However I'm still skeptical about the two-argument version of aiter() (see my previous message about this). Do you have any indication that a use case for that exists? --Guido On Sat, Mar 20, 2021 at 11:17 AM Yury Selivanov <yselivanov...@gmail.com> wrote: > Hi Joshua, > > First of all, thanks for working on this! I quickly looked over the PR and > it looks ready to be merged, great work. > > I've been oscillating between wanting to have aiter/anext as builtins and > putting them into the operators module for quite a while. On the one hand > asynchronous iteration is a niche thing compared to regular iteration, on > the other, 'async for' and asynchronous generators are language constructs. > Overall, I'm leaning towards having them as builtins. That would make them > more discoverable and slightly more convenient to use with things like > 'aclosing', especially if the code is following the "import only modules" > convention. And in my opinion there's almost no overhead with regards to > how big is the list of builtins (especially with the globals opcode cache). > > So my personal vote would be to make them builtins and merge your PR as is. > > Yury > > > On Fri, Mar 19, 2021 at 3:18 PM Joshua Bronson <jabron...@gmail.com> > wrote: > >> Thanks for all the feedback so far (and for the kind words, Guido! 😊). >> >> Discussion here so far is converging on resurrecting my original PR from >> 2018 adding these to operator. Anyone else we should hear from before >> considering the more recent PR not worth pursuing for now? Would be good to >> hear from Yury given his previous feedback, but seems like he’s been too >> busy to respond. Should we wait (for some limited amount of time, in light >> of the upcoming 3.10 feature freeze?) for more feedback? >> >> I’m ready to update whichever PR we’re going ahead with, once I know >> which one that is. >> >> Thanks, >> Josh >> >> >> On Fri, Mar 19, 2021 at 17:23 Brett Cannon <br...@python.org> wrote: >> >>> I personally would be okay with aiter() (with the modern API 😉) and >>> next() in the `operator` module. There's already precedent in having things >>> there that are rarely used directly but still implement the use of a >>> special method, e.g. operator.index() ( >>> https://docs.python.org/3/library/operator.html#operator.index). >>> >>> On Fri, Mar 19, 2021 at 10:29 AM Guido van Rossum <gu...@python.org> >>> wrote: >>> >>>> 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/ >>>> >>> _______________________________________________ >> 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/MOE5OKHMHS6BU2PSTOLHC73LW2A3JHKF/ >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > > > -- > Yury > _______________________________________________ > 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/ZINKDAHIRB5GWJPUPREZFZ2VBM6AJP7F/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
_______________________________________________ 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/RVVMZ4EGRILLWZOSXSKXKVCHJR34CVVY/ Code of Conduct: http://python.org/psf/codeofconduct/
