On Wed, Sep 8, 2021 at 12:49 PM Yury Selivanov <yseliva...@gmail.com> wrote:
> We have already merged it, the fix is part of the rc2. > Thanks! (If we were on Discourse I would have left a ♥ instead 😃) > > yury > > > On Wed, Sep 8 2021 at 12:48 PM, Brett Cannon <br...@python.org> wrote: > >> On Thu, Sep 2, 2021 at 7:43 PM Yury Selivanov <yselivanov...@gmail.com> >> wrote: >> >>> Comments inlined: >>> >>> On Thu, Sep 2, 2021 at 6:23 PM Guido van Rossum <gu...@python.org> >>> wrote: >>> >>>> First of all, we should ping Yury, who implemented `async for` about 6 >>>> years ago (see PEP 492), and Joshua Bronson, who implemented aiter() and >>>> anext() about 5 months ago (see https://bugs.python.org/issue31861). >>>> I've CC'ed them here. >>>> >>> >>> Looks like PyAiter_Check was added along with the aiter/anext builtins. >>> I agree it's unnecessary to check for __aiter__ in it, so I let's just fix >>> it. >>> >>> >>> >>>> >>>> My own view: >>>> >>>> A. iter() doesn't check that the thing returned implements __next__, >>>> because it's not needed -- iterators having an __iter__ methor is a >>>> convention, not a requirement. >>>> >>> >>> Yeah. >>> >>> >>>> You shouldn't implement __iter__ returning something that doesn't >>>> implement __iter__ itself, because then "for x in iter(a)" would fail even >>>> though "for x in a" works. But you get an error, and anyone who implements >>>> something like that (or uses it) deserves what they get. People know about >>>> this convention and the ABC enforces it, so in practice it will be very >>>> rare that someone gets bitten by this. >>>> >>>> B. aiter() shouldn't need to check either, for exactly the same reason. >>>> I *suspect* (but do not know) that the extra check for the presence of >>>> __iter__ is simply an attempt by the implementer to enforce the convention. >>>> There is no *need* other than ensuring that "async for x in aiter(a)" works >>>> when "async for x in a" works. >>>> >>> >>> I agree. >>> >> >> [SNIP] >> >> >> >>> Bottom line: let's fix PyAiter_Check to only look for __anext__. It's a >>> new function so we can still fix it to reflect PyIter_Check and not worry >>> about anything. >>> >> >> I don't know if Pablo wants such a change in 3.10 since we are at rc2 at >> this point, so this might have to wait for 3.11 (although there's no >> deprecation here since it's a loosening of requirements so it could go in >> straight away). >> >
_______________________________________________ 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/3ZNA6R65UG26OHB5CNVRWN7YBJYMXV7U/ Code of Conduct: http://python.org/psf/codeofconduct/
