The python3.9 code creates the futures set two times.
We can create this set before, avoiding the second creation.

This python3.9 behaviour breaks the aiokafka library, because it gives an iterator to that function, so the second iteration become empty.

Are you suggesting this is a bug, or is it just a suggested code cleanup? I ask because the docs suggest that a set should be passed:
https://docs.python.org/3/library/asyncio-task.html#asyncio.wait

And the docstring says it should be a sequence:
https://github.com/python/cpython/blob/d1a0a960ee493262fb95a0f5b795b5b6d75cecb8/Lib/asyncio/tasks.py#L373-L376

So while code cleanup is okay, I'm not sure support for general iterator arguments can / should be guaranteed.

The current error message is way too cryptic anyway.  And restricting it to the set type only, as in docs, will certainly break a lot of code (passing a list is quite common).

> Are you suggesting this is a bug, or is it just a suggested code cleanup?

It is a suggested code cleanup.

My point is that the code creates two sets based on the Sequence `fs`.
I think it is better if the code creates the set just one time, instead of
two times.

Em dom., 25 de out. de 2020 às 18:57, Chris Jerdonek <report@bugs.python.org>
escreveu:

>
> Chris Jerdonek <chris.jerdonek@gmail.com> added the comment:
>
> Are you suggesting this is a bug, or is it just a suggested code cleanup?
> I ask because the docs suggest that a set should be passed:
> https://docs.python.org/3/library/asyncio-task.html#asyncio.wait
>
> And the docstring says it should be a sequence:
>
> https://github.com/python/cpython/blob/d1a0a960ee493262fb95a0f5b795b5b6d75cecb8/Lib/asyncio/tasks.py#L373-L376
>
> So while code cleanup is okay, I'm not sure support for general iterator
> arguments can / should be guaranteed.
>
> ----------
> nosy: +chris.jerdonek
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue42140>
> _______________________________________
>

Your change makes perfect sense to me. It would be a backport-only change as the 2nd set creation is actually getting removed for the development version (3.10) to finalize the deprecation of wait's coroutine scheduling.

If it's just a code cleanup and not a bugfix though, it shouldn't be backported. But yes, as a cleanup it's fine. And even if it's expected to go away later, it's okay to do now.

I believe the documentation may be referring to the English set and not a Python set, but I could be wrong.

Yury changed the wording from sequence to set in 3.7, but we didn't document a breaking change as far as I know. The purpose of those set constructions was to handle the many things other than a set that can be passed in that may have non-unique values. Early asyncio documentation included examples of passing wait() a list.

I wouldn't be surprised if there are other libraries or apps out there for which removing iterator support was an accidentally-breaking change and it may be strange if this is only is broken in 3.9.x, but working both before and after.

> I wouldn't be surprised if there are other libraries or apps out there
for which removing iterator support was an accidentally-breaking change and
it may be strange if this is only is broken in 3.9.x, but working both
before and after.

Justin, when the deprecation message has been removed, the iterator will
works again, because the code will iterate just one time.
So the behaviour you describe will happen anyway.

My changes proposal is a “improvement”, because the second iteration can be
made on the already created set.

I think that change make senses because it removes unnecessary data
creation.

Em ter, 27 de out de 2020 às 00:24, Justin Arthur <report@bugs.python.org>
escreveu:

>
> Justin Arthur <justinarthur@gmail.com> added the comment:
>
> I believe the documentation may be referring to the English set and not a
> Python set, but I could be wrong.
>
> Yury changed the wording from sequence to set in 3.7, but we didn't
> document a breaking change as far as I know. The purpose of those set
> constructions was to handle the many things other than a set that can be
> passed in that may have non-unique values. Early asyncio documentation
> included examples of passing wait() a list.
>
> I wouldn't be surprised if there are other libraries or apps out there for
> which removing iterator support was an accidentally-breaking change and it
> may be strange if this is only is broken in 3.9.x, but working both before
> and after.
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <https://bugs.python.org/issue42140>
> _______________________________________
>

> So the behaviour you describe will happen anyway.
Unless we make your change against the 3.9 branch, in which case the fix will make it into the 3.9.x series of patch releases.

I opened https://bugs.python.org/issue42230 to make the documentation reflect the reality in this matter.

New changeset 7e5ef0a5713f968f6e942566c78bf57ffbef01de by Diogo Dutra in branch 'master':
bpo-42140: Improve asyncio.wait function (GH-22938)
https://github.com/python/cpython/commit/7e5ef0a5713f968f6e942566c78bf57ffbef01de

New changeset 33922cb0aa0c81ebff91ab4e938a58dfec2acf19 by Miss Islington (bot) in branch '3.9':
bpo-42140: Improve asyncio.wait function (GH-22938)
https://github.com/python/cpython/commit/33922cb0aa0c81ebff91ab4e938a58dfec2acf19

Thanks for the change and for the discussion to everybody involved. The PR makes sense and I've already merged it.