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
assumed
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 co
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 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
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
> 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 h
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
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
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
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 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
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
12 matches
Mail list logo
