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
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
>
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
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
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
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,
> On 20 Mar 2021, at 04:39, Guido van Rossum wrote:
>
> Honestly this is an example of a module that would have been better off
> outside the stdlib.
>
> On Fri, Mar 19, 2021 at 14:43 Senthil Kumaran wrote:
> On Mon, Feb 15, 2021 at 8:36 AM Faisal Mahmood
> wrote:
> >
> > Hello,
> >
> > I
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
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
We would like to present for feedback a new version of PEP 654, which
incorporates the feedback we received in the discussions so far:
https://www.python.org/dev/peps/pep-0654/
The reference implementation has also been updated along with the PEP.
The changes we made since the first post are:
1.
Hi everyone,
We've got to the stage now with PEP 646 that we're feeling pretty happy
with it. So far though we've mainly been workshopping it in typing-sig, so
as PEP 1 requires we're asking for some feedback here too before submitting
it to the steering council.
If you have time over the next
Thank you for taking the time to look at this. I do agree with Guido to an
extent, the ipaddress module is by far the most comprehensive and useful
standard IP library I've seen in a programming language, I was surprised
when I first found it's existence. But being fairly new to Python, I
12 matches
Mail list logo
