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 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 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-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/5XUVPB5H... 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

Now is a good time to ask: what are the criteria for adding functions to the builtins module? Is there a written record of those criteria? Thanks! On Fri, Mar 19, 2021 at 1:55 PM Luciano Ramalho 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 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 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 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-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/5XUVPB5H... 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

-- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Technical Principal at ThoughtWorks | Twitter: @ramalhoorg

Sample size of 1: I have code calling __aiter__ and __anext__. It would be nice to have representative functions—in some module—for the 3.10 release. I would think the bar for inclusion in builtins should be quite high. Looking at what's in the operator module, it does seem like a more appropriate location than builtins; if setitem doesn't warrant inclusion in builtins, hard to justify aiter and anext. Paul On Fri, 2021-03-19 at 13:55 -0300, Luciano Ramalho 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 wrote:

...

Thanks for taking a look at this, Luciano.

Yury immediately replied 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 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, 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 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 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-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/5XUVPB5H...

...

...

...

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

_______________________________________________ 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/R3I7WIXN... Code of Conduct: http://python.org/psf/codeofconduct/

On Fri, 2021-03-19 at 10:22 -0700, Guido van Rossum wrote:

I’m not convinced that we need aiter(x, sentinel) at all — for iter() it’s mostly a legacy compatibility API.

I'm feel like I'm going to learn something today. To date, the pattern I've used for getting the first item from an iterable: next(iter(i)) What's the recommended alternative? Paul

I did learn something today! 🙂 On Fri, 2021-03-19 at 10:37 -0700, Guido van Rossum wrote:

I was only talking about the two-argument version, iter(x, sentinel). Betcha you didn’t even know that existed. :-)

On Fri, Mar 19, 2021 at 10:34 Paul Bryan wrote:

...

On Fri, 2021-03-19 at 10:22 -0700, Guido van Rossum wrote:

...

I’m not convinced that we need aiter(x, sentinel) at all — for iter() it’s mostly a legacy compatibility API.

I'm feel like I'm going to learn something today. To date, the pattern I've used for getting the first item from an iterable:

next(iter(i))

What's the recommended alternative?

Paul

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. On Fri, Mar 19, 2021 at 2:22 PM Guido van Rossum 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 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 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 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 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-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/5XUVPB5H... 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-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/R3I7WIXN... Code of Conduct: http://python.org/psf/codeofconduct/

-- --Guido (mobile)

-- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Technical Principal at ThoughtWorks | Twitter: @ramalhoorg

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 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 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 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 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 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 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-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/5XUVPB5H... 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-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/R3I7WIXN... 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-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/4JLY7U6D...

...

Code of Conduct: http://python.org/psf/codeofconduct/

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 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 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 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 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 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 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 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-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/5XUVPB5H... > 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-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/R3I7WIXN... 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-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/4JLY7U6D...

...

Code of Conduct: http://python.org/psf/codeofconduct/

_______________________________________________ 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/MOE5OKHM... Code of Conduct: http://python.org/psf/codeofconduct/

-- Yury

On Sat, Mar 20, 2021 at 2:35 PM Guido van Rossum wrote:

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?

In my experience this isn't a popular feature. Now that I looked into the docs, I *think* I remember using it once myself. Generally if I need this functionality I'd just write a simple generator. Not that this is a definitive indicator of the popularity of this thing; I'm just sharing my experience. That said I wouldn't mind aiter() supporting the two-arguments mode as it could make it easier to convert some sync code bases (that use greenlets, for example) to async. And given that async iteration mirrors the sync iteration protocol pretty closely, I think that aiter() fully mirroring iter() is expected. I do realize that my arguments here are weak, so my vote is +0 to support the two-arguments mode. Yury

On Sat, Mar 20, 2021 at 7:49 PM Chris Angelico wrote:

...

That said I wouldn't mind aiter() supporting the two-arguments mode as it could make it easier to convert some sync code bases (that use greenlets, for example) to async. And given that async iteration mirrors

On Sun, Mar 21, 2021 at 1:30 PM Yury Selivanov wrote: the sync iteration protocol pretty closely, I think that aiter() fully mirroring iter() is expected. I do realize that my arguments here are weak, so my vote is +0 to support the two-arguments mode.

...

I'm -0.5 on two-argument aiter(), mainly because YAGNI. Two-arg iter() might be worth a single bullet point somewhere in a list of "translating blocking code to nonblocking".

It was made of one use case: iter(f.readline, ""). -- --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-c...