[3.8] Make the 3.10 related xfails non-strict #7178
Conversation
|
Opening as a draft without the changelog things for now. I am not sure this is the bast approach to solving our issue. |
Just to clarify, this isn’t specific to Python 3.11, as it was working in Fedora 37 at one point, and I see the same thing on Fedora 36 with Python 3.10.9. Perhaps it was triggered by a dependency update. |
|
@webknjaz usually has some opinions on xfail. Personally, these tests look pretty useless to me, they are testing something that we shouldn't be supporting (atleast by Python 3.7). So, I'm happy to merge this unless @webknjaz says otherwise (I'd also be happy just removing the tests). I am curious why it would succeed on Fedora though. The only way I can imagine it passing is if Fedora is patching Python, or otherwise modifying its behaviour, so it doesn't emit those deprecation warnings. |
|
We have backported this: python/cpython#100412 -- but the tests started to xpass even sooner :/ |
|
Looks like xfails are conditional on python 3.10+. If the CI starts to pass on the latest patch versions of CPython for everything in the matrix, I don't see why we'd need to keep the xfail marks at all. @hroncok FYI we've pretty much decided not to make another release from the 3.8 branch, so this PR should probably be targeting 3.9 and master instead. Of course, we can merge the PR into 3.8 if needed for downstream, but this doesn't mean that it'll ever get released from this branch. |
Based on the comment in that PR, this will start xfailing again in Python 3.12. So maybe we just need to change the xfail conditional to py3.12+ |
We've already patched the Fedora package to do this, just trying to be good citizens here and offer the patch upstream instead of keeping it downstream-only. Take it, leave it, put it somewhere else, delete the tests, or do whatever you see fit :) We would love to be eventually able to drop the patch from Fedora, but if that's in a 3.9.x release, that's fine. |
aio-libs/aiohttp#7178 (comment) git-svn-id: file:///srv/repos/svn-community/svn@1445521 9fca08f4-af9d-4005-b8df-a31f2cc04f65
aio-libs/aiohttp#7178 (comment) git-svn-id: file:///srv/repos/svn-community/svn@1445521 9fca08f4-af9d-4005-b8df-a31f2cc04f65
webknjaz
added
the
bot:chronographer:skip
We see xpasses in Fedora with Python 3.11.1 or 3.10.9:
=================================== FAILURES ===================================
__________________________ test_default_loop[pyloop] ___________________________
[XPASS(strict)] No idea why ClientRequest() is constructed out of loop but it calls `asyncio.get_event_loop()`
____________________ TestStreamReader.test_ctor_global_loop ____________________
[XPASS(strict)] No idea why ClientRequest() is constructed out of loop but it calls `asyncio.get_event_loop()`
__________________________ test_set_loop_default_loop __________________________
[XPASS(strict)] No idea why _set_loop() is constructed out of loop but it calls `asyncio.get_event_loop()`
Codecov Report
@@ Coverage Diff @@
## 3.8 #7178 +/- ##
==========================================
- Coverage 97.40% 97.38% -0.02%
==========================================
Files 107 107
Lines 30996 30996
Branches 3924 3924
==========================================
- Hits 30191 30186 -5
- Misses 602 605 +3
- Partials 203 205 +2
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 3 files with indirect coverage changes 📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
What do these changes do?
We see xpasses in Fedora with Python 3.11.1 or 3.10.9:
Are there changes in behavior for the user?
No.
Related issue number
No.
Checklist
CONTRIBUTORS.txtCHANGESfolder<issue_id>.<type>for example (588.bugfix)issue_idchange it to the pr id after creating the pr.feature: Signifying a new feature..bugfix: Signifying a bug fix..doc: Signifying a documentation improvement..removal: Signifying a deprecation or removal of public API..misc: A ticket has been closed, but it is not of interest to users.