[Python-Dev] Re: Merge Request Review Reminder

[Faisal Mahmood]

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 this was the Python way and it has been extremely useful to me as a
Network Automation Engineer at my company.  One way I have always seen
Python as useful is that I don't have to keep reinventing the wheel or
wasting time writing code that could have already been written in a
standard way, I think it's one of the many important reasons why people
choose Python, because the code for what they want to do probably already
exists in stdlib.  But whether this library should be in stdlib or not is
beyond the scope of my PR, I think we are in the situation we are in and we
should make sure the stdlib is maintained and kept up to date in the mean
time.

Here are the motivations for getting this added:
FEELS INCOMPLETE: This library includes the subnet_of and supernet_of
methods, they will effectively allow you to break down a network into
smaller subnets (i.e. go down) or find the networks parent network (i.e. go
up).  But what they are missing is finding the next closest network (i.e.
go sideways) - (which reminds me, perhaps I should implement a
prev_network() as well?).  It's always been a case where this library has
felt incomplete as it lets you go in the up and down direction but omits
the sideways direction.
IT'S COMPLICATED: Finding the next closest network is not a trivial task to
do in your head and it's difficult to understand, from my experience the
most efficient way of doing it is on the binary level.  When I first had a
use case to do this, it took me a good amount of time trying to understand
this algorithm and implement it, I'm certain there will be many people out
there struggling with this and reinventing the wheel.  By adding this into
the ipaddress module, we help simplify this task and improve peoples
network knowledge.  A lot of users of the ipaddress module are likely to be
Network Engineers who have little programming experience, they would
probably not be experienced enough to implement something like this or get
involved in feeding it back to the Python project.
IT'S NEEDED: Personally, I almost exclusively work with IPv4 networks and
one very common use case we get is slicing up networks to use them as
efficiently as possible.  For example, if I am given a network of
10.250.1.0/16 and I need to reserve a /21 for some servers within that
range, I would initially just reserve at the start of the network, i.e.
10.250.1.0/21 - very simple.  But now, say someone comes along and says
they want a /19 from the same network, then it's not so simple anymore.
The 10.250.1.0/21 network runs from 10.250.1.0-10.250.7.254 - you can't
just take the broadcast address and add 1 to it (i.e. 10.250.8.0/19 would
be invalid), the next closest /19 network is actually infact 10.250.32.0/19.
There is no way to figure this out currently in the ipaddress module, even
though it is a very common practice that is done by network engineers
manually.  A helpful way to illustrate this is by playing around on this
VPC Subnet Builder here: https://tidalmigrations.com/subnet-builder/ - You
can see a screenshot of my example below:
[image: image.png]
I hope this helps - please let me know if you need anything else.  I would
not have spent any time on this if I didn't think it was a valuable and
fitting element of this module.  To me it seemed like a very important
omission, but that's just my two cents.


On Sat, 20 Mar 2021 at 03: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 hope you are all well, I currently have an issue / merge request that
>> has become stale and as per the guidelines I am sending this e-mail to
>> request someone to review it for me please.
>> >
>> > Issue Number: 42861 (https://bugs.python.org/issue42861)
>> > Pull Request: 24180 (https://github.com/python/cpython/pull/24180)
>> >
>>
>> Could you share some motivation references that could help explain why
>> this next_network method will be helpful? Is this common enough to
>> warrant a method in the stdlib IP-Address module?
>> If there is prior-art in other external libraries or libraries of
>> other languages, that will be helpful to know and review too.
>>
>> I had looked at this a month ago when you pinged for review, but I
>> could not immediately determine the benefit of having this method in
>> stdlib, irrespective of implementation correctness or API Signature.
>> I also lack extensive experience with ipv6.
>>
>> Thanks,
>> Senthil
>> ___
>> Python-Dev mailing list -- python-

[Python-Dev] PEP 646 (Variadic Generics): final call for comments

[Matthew Rahtz via Python-Dev]

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 couple of weeks, please take a look at the
current draft and let us know your thoughts:
https://www.python.org/dev/peps/pep-0646/ (Note that the final couple of
sections are out of date; https://github.com/python/peps/pull/1880
clarifies which grammar changes would be required, now that PEP 637 has
been rejected. We also have a second PR in progress at
https://github.com/python/peps/pull/1881 clarifying some of the motivation.)

Thanks!
Matthew and Pradeep
___
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/5GWS2GGVJ4PAMOWM6YVVKZVMR5BRFRGV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] PEP 654: Exception Groups and except* [REPOST]

[Irit Katriel via Python-Dev]

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. Instead of ExceptionGroup(BaseException), we will have two new builtin
types: BaseExceptionGroup(BaseException) and
ExceptionGroup(BaseExceptionGroup, Exception).
This is so that "except Exception" catches ExceptionGroups (but not
BaseExceptionGroups). BaseExceptionGroup.__new__ inspects the wrapped
exceptions, and if they are all Exception subclasses, it creates an
ExceptionGroup instead of a BaseExceptionGroup.

2. The exception group classes are not final - they can be subclassed and
split()/subgroup() work correctly if the subclass overrides the derive()
instance method as described here:
https://www.python.org/dev/peps/pep-0654/#subclassing-exception-groups

3. We had some good suggestions on formatting exception groups, which we
have implemented as you can see in the output shown for the examples in the
PEP.

4. We expanded the section on handling Exception Groups, to show how
subgroup can be used (with side effects) to do something for each leaf
exception, and how to iterate correctly when the tracebacks of leaf
exceptions are needed:
https://www.python.org/dev/peps/pep-0654/#handling-exception-groups

5. We expanded the sections on rationale and backwards compatibility to
explain our premise and expectations regarding how exception groups will be
used and how the transition to using them will be managed.

6. We added several items to the rejected ideas section.

We did not receive any comments (or make any changes) to the proposed
semantics of except*, hopefully this is because everyone thought they are
sensible.

Irit, Yury and Guido
___
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/MQ2UCSQ2ZC4FIGT7KSVI6BJA4FCXSOCL/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Yury Selivanov]

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

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

[Guido van Rossum]

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
builtins for __iter__ and __next__.

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?

--Guido

On Sat, Mar 20, 2021 at 11:17 AM Yury Selivanov 
wrote:

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

[Python-Dev] Re: Merge Request Review Reminder

[Jakub Stasiak]

> 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 hope you are all well, I currently have an issue / merge request that has 
> > become stale and as per the guidelines I am sending this e-mail to request 
> > someone to review it for me please.
> >
> > Issue Number: 42861 (https://bugs.python.org/issue42861)
> > Pull Request: 24180 (https://github.com/python/cpython/pull/24180)
> >
> 
> Could you share some motivation references that could help explain why
> this next_network method will be helpful? Is this common enough to
> warrant a method in the stdlib IP-Address module?
> If there is prior-art in other external libraries or libraries of
> other languages, that will be helpful to know and review too.
> 
> I had looked at this a month ago when you pinged for review, but I
> could not immediately determine the benefit of having this method in
> stdlib, irrespective of implementation correctness or API Signature.
> I also lack extensive experience with ipv6.
> 
> Thanks,
> Senthil


I don’t know if this is gonna support Faisal’s cause (“It’s used in a third 
party library in the wild, that means stdlib could use it!”) or the exact 
opposite (“it’s provided by a third party library, so may as well use third 
party library and stdlib doesn’t necessarily need this”) but the quite popular 
netaddr library that I’m a maintainer of does have IPNetwork.next() and 
IPNetwork.previous() methods[1][2]. The main difference is that in netaddr:

* next() and previous() can produce networks arbitrary number of steps away, 
not just the first closest network forwards or backwards
* going from a network to its supernetwork or subnetwork is done through a 
separate set of supernet() and subnet() methods[3][4]

I can’t say how many library users actually consume this particular section of 
the API, of course, but I expect this API to be used and it seems rather useful.

Best,
Jakub

[1] https://netaddr.readthedocs.io/en/latest/api.html#netaddr.IPNetwork.next
[2] https://netaddr.readthedocs.io/en/latest/api.html#netaddr.IPNetwork.previous
[3] https://netaddr.readthedocs.io/en/latest/api.html#netaddr.IPNetwork.subnet
[4] https://netaddr.readthedocs.io/en/latest/api.html#netaddr.IPNetwork.supernet
___
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/NN2OTO7Z4326CL5T3SLJQDZBRKZXOIPG/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Daniel Pope]

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 contribution was to unroll that to sync Python code,
and then port that to (sync) C code. It was a lot of effort and a lot of
code - several hundred lines and 4(?) new types. The Python code was a few
lines - very readable and likely to be practically as fast. We weren't
writing this in C to speed it up or to make the code better, but because we
*had to*.

Implementing async functionality in C is a pain because to implement an
awaitable type you need not just that awaitable type, but a new type to
represent the iterator that am_await returns. I could imagine having
generic type objects and other helpers for implementing async PyObjects in
C but I don't really envisage anyone doing that; if you want to write async
helpers for Python the best framework is Python.

As Josh can attest I was in two minds while implementing this change; I
argued firstly that having them in the operator module is fine, and later,
that if we want async builtins in general, maybe we could implement them in
Python and freeze them into the binary. We pushed on with the C approach
mostly because we were already 70% done, and this was what Yury asked for,
so it seemed more likely that this would get merged.

But, if we're still discussing whether this should be merged in builtins or
operator, and that dictates whether it is in Python or C, I'm 100% behind
having this code be Python.
___
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/VZFDUDH3NIBZX4ADPJ4E7VG2WAWOUBAA/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

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 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 contribution was to unroll that to sync Python code,
> and then port that to (sync) C code. It was a lot of effort and a lot of
> code - several hundred lines and 4(?) new types. The Python code was a few
> lines - very readable and likely to be practically as fast. We weren't
> writing this in C to speed it up or to make the code better, but because we
> *had to*.
>
> Implementing async functionality in C is a pain because to implement an
> awaitable type you need not just that awaitable type, but a new type to
> represent the iterator that am_await returns. I could imagine having
> generic type objects and other helpers for implementing async PyObjects in
> C but I don't really envisage anyone doing that; if you want to write async
> helpers for Python the best framework is Python.
>
> As Josh can attest I was in two minds while implementing this change; I
> argued firstly that having them in the operator module is fine, and later,
> that if we want async builtins in general, maybe we could implement them in
> Python and freeze them into the binary. We pushed on with the C approach
> mostly because we were already 70% done, and this was what Yury asked for,
> so it seemed more likely that this would get merged.
>
> But, if we're still discussing whether this should be merged in builtins
> or operator, and that dictates whether it is in Python or C, I'm 100%
> behind having this code be Python.
> ___
> 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/VZFDUDH3NIBZX4ADPJ4E7VG2WAWOUBAA/
> 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-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/7WEDTRUE4RIA6K42OLXP55VIYRDOSLOP/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Yury Selivanov]

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

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

[Yury Selivanov]

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 them as builtins makes a bit more sense than
exiling them into the operators module. Given that they are the last
two missing pieces I think we can merge those couple hundred lines of
C. And if we drop the 2-args version of aiter() we'll have a more
reasonable diff.

Yury

On Sat, Mar 20, 2021 at 4:45 PM 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 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 contribution was to unroll that to sync Python code, and 
> then port that to (sync) C code. It was a lot of effort and a lot of code - 
> several hundred lines and 4(?) new types. The Python code was a few lines - 
> very readable and likely to be practically as fast. We weren't writing this 
> in C to speed it up or to make the code better, but because we *had to*.
>
> Implementing async functionality in C is a pain because to implement an 
> awaitable type you need not just that awaitable type, but a new type to 
> represent the iterator that am_await returns. I could imagine having generic 
> type objects and other helpers for implementing async PyObjects in C but I 
> don't really envisage anyone doing that; if you want to write async helpers 
> for Python the best framework is Python.
>
> As Josh can attest I was in two minds while implementing this change; I 
> argued firstly that having them in the operator module is fine, and later, 
> that if we want async builtins in general, maybe we could implement them in 
> Python and freeze them into the binary. We pushed on with the C approach 
> mostly because we were already 70% done, and this was what Yury asked for, so 
> it seemed more likely that this would get merged.
>
> But, if we're still discussing whether this should be merged in builtins or 
> operator, and that dictates whether it is in Python or C, I'm 100% behind 
> having this code be Python.
> ___
> 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/VZFDUDH3NIBZX4ADPJ4E7VG2WAWOUBAA/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
 Yury
___
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/CFQ7Y677N3A5GQWU3M3AGMFZDIVWWP7K/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Chris Angelico]

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

ChrisA
___
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/3CXVPF44ZDQDSS77JJRCMLUVNPLZ3KJ7/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Guido van Rossum]

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 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.
> >
>
> 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?)*

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