fancidev
fancidev
@xitop, good suggestion. A somewhat precise definition is that a task scheduled by create_task is started in the next event loop iteration, after callbacks scheduled before the create_task call are...
Why should we not say that the created task will start in the next event loop iteration? After all, it is scheduled by call_soon and the [doc on call_soon](https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.loop.call_soon) says:...
According to @gvanrossum’s comments, the task is expected to start after the current loop iteration but before any blocking I/O polling. The current implementation starts the task in the next...
But await asyncio.sleep(0) does not *ensure* the task is started… it’s just one of the ways to make it *possible* for a task to get started “soon”; other ways being...
Correction: awaiting anything is not enough… the thing being awaited need to have a suspension point in it soon, so asyncio.sleep(0) is good, so as Futures that are not yet...
@sobolevn, thanks for reviewing! I also removed the NEWS entry. Hope it's good now!
Another CI test run with the same error (Python 3.7): [Python-3.7-PySide2-macos-latest](https://github.com/fancidev/qtinter/actions/runs/3227541398/jobs/5282483478)
@sobolevn: The issue still exists in recent code -- here is a CI run error example on 3.11.0-rc1: https://github.com/fancidev/qtinter/actions/runs/3219024415/jobs/5263887528#logs @gvanrossum: I proposed a PR just now. Thanks for reviewing! @akulakov:...
~~If I’m not mistaken, an O(n) instead of O(nlnn) algorithm is possible to compute the trimmed mean?~~ scipy is already using an O(n) algorithm (by calling `numpy.partition`). Some overhead exists...
> it's correct in that it describes an equivalent algorithm. The important part is that it creates a copy of the array and operates on it, which for large arrays...