Am 15.11.2022 um 11:21 hat Hanna Reitz geschrieben: > On 15.11.22 11:14, Kevin Wolf wrote: > > Am 15.11.2022 um 00:58 hat John Snow geschrieben: > > > On Mon, Nov 14, 2022 at 5:56 AM Kevin Wolf <kw...@redhat.com> wrote: > > > > Am 11.11.2022 um 20:20 hat Stefan Hajnoczi geschrieben: > > > > > > Hanna Reitz (9): > > > > > > block/mirror: Do not wait for active writes > > > > > > block/mirror: Drop mirror_wait_for_any_operation() > > > > > > block/mirror: Fix NULL s->job in active writes > > > > > > iotests/151: Test that active mirror progresses > > > > > > iotests/151: Test active requests on mirror start > > > > > > block: Make bdrv_child_get_parent_aio_context I/O > > > > > > block-backend: Update ctx immediately after root > > > > > > block: Start/end drain on correct AioContext > > > > > > tests/stream-under-throttle: New test > > > > > Hi Hanna, > > > > > This test is broken, probably due to the minimum Python version: > > > > > https://gitlab.com/qemu-project/qemu/-/jobs/3311521303 > > > > This is exactly the problem I saw with running linters in a gating CI, > > > > but not during 'make check'. And of course, we're hitting it during the > > > > -rc phase now. :-( > > > I mean. I'd love to have it run in make check too. The alternative was > > > never seeing this *anywhere* ... > > What is the problem with running it in 'make check'? The additional > > dependencies? If so, can we run it automatically if the dependencies > > happen to be fulfilled and just skip it otherwise? > > > > If I have to run 'make -C python check-pipenv' manually, I can guarantee > > you that I'll forget it more often than I'll run it. > > > > > ...but I'm sorry it's taken me so long to figure out how to get this > > > stuff to work in "make check" and also from manual iotests runs > > > without adding any kind of setup that you have to manage. It's just > > > fiddly, sorry :( > > > > > > > But yes, it seems that asyncio.TimeoutError should be used instead of > > > > asyncio.exceptions.TimeoutError, and Python 3.6 has only the former. > > > > I'll fix this up and send a v2 if it fixes check-python-pipenv. > > > Hopefully this goes away when we drop 3.6. I want to, but I recall > > > there was some question about some platforms that don't support 3.7+ > > > "by default" and how annoying that was or wasn't. We're almost a year > > > out from 3.6 being EOL, so maybe after this release it's worth a crack > > > to see how painful it is to move on. > > If I understand the documentation right, asyncio.TimeoutError is what > > you should be using either way. That it happens to be a re-export from > > the internal module asyncio.exceptions seems to be more of an > > implementation detail, not the official interface. > > Oh, so I understood > https://docs.python.org/3/library/asyncio-exceptions.html wrong. I took > that to mean that as of 3.11, `asyncio.TimeoutError` is a deprecated alias > for `asyncio.exceptions.TimeoutError`, but it’s actually become an alias for > the now-built-in `TimeoutError` exception. I think.
Not just "now-built-in", it has been built in before (starting from 3.3). But AIUI, asyncio used to use its own separate exception class (asyncio.TimeoutError, in some versions re-exported from the exceptions submodule) instead of the built-in one, and in 3.11 it now reuses the built-in one instead of defining a separate custom one. Kevin
