[Python-Dev] Re: aiter/anext review request

On Sat, Mar 20, 2021 at 7:49 PM Chris Angelico wrote: > On Sun, Mar 21, 2021 at 1:30 PM Yury Selivanov > 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 g

[Python-Dev] Re: aiter/anext review request

On Sun, Mar 21, 2021 at 1:30 PM Yury Selivanov 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 the sync iteration > prot

[Python-Dev] Re: aiter/anext review request

Hi Daniel, I agree that coding async in C is complicated, I've done a fair share of that and can attest that the code is not straightforward or easily maintainable. But in this very case I think we care more about discoverability of these two functions and the overall developer experience. Having

[Python-Dev] Re: aiter/anext review request

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 loo

[Python-Dev] Re: aiter/anext review request

The operator module is also C. I am pleading to remove the 2nd arg to aiter, which should simplify the code. On Sat, Mar 20, 2021 at 16:45 Daniel Pope wrote: > As someone who was involved in implementing these, I think they should not > be in builtins if that means they have to be in C. > > My a

[Python-Dev] Re: aiter/anext review request

As someone who was involved in implementing these, I think they should not be in builtins if that means they have to be in C. My argument is from a point of maintainability. Writing them was plenty of effort in the first place; Josh had written them in idiomatic async Python in the first place, my

[Python-Dev] Re: aiter/anext review request

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 buil

[Python-Dev] Re: aiter/anext review request

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

[Python-Dev] Re: aiter/anext review request

On 3/19/2021 6:11 PM, Joshua Bronson wrote: Discussion here so far is converging on resurrecting my original PR from 2018 adding these to operator. I prefer this too. -- Terry Jan Reedy ___ Python-Dev mailing list -- python-dev@python.org To unsubsc

[Python-Dev] Re: aiter/anext review request

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 fro

[Python-Dev] Re: aiter/anext review request

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.htm

[Python-Dev] Re: aiter/anext review request

On Fri, 19 Mar 2021 at 14:38, 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 pat

[Python-Dev] Re: aiter/anext review request

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 as

[Python-Dev] Re: aiter/anext review request

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 -0

[Python-Dev] Re: aiter/anext review request

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

[Python-Dev] Re: aiter/anext review request

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

[Python-Dev] Re: aiter/anext review request

No, and there shouldn’t be written criteria. That would just give people more incentive to argue forever. On Fri, Mar 19, 2021 at 10:12 Luciano Ramalho wrote: > 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

[Python-Dev] Re: aiter/anext review request

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

[Python-Dev] Re: aiter/anext review request

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

[Python-Dev] Re: aiter/anext review request

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

[Python-Dev] Re: aiter/anext review request

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 rarel

[Python-Dev] Re: aiter/anext review request

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 > c

[Python-Dev] Re: aiter/anext review request

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 l