Closed shamrin closed 3 years ago
The test error is from Python 3.10 which dropped a heap of loop=loop
parameters from Future
, Event
et al.
I'm building a minimal patch; more extensive de-loop-argument-ization (in trio-asyncio
proper) makes sense but requires deprecation warnings.
Merging #94 (a18c2b4) into master (b93c320) will increase coverage by
1.16%
. The diff coverage is87.50%
.
@@ Coverage Diff @@
## master #94 +/- ##
==========================================
+ Coverage 80.64% 81.81% +1.16%
==========================================
Files 11 11
Lines 1240 1193 -47
Branches 172 172
==========================================
- Hits 1000 976 -24
+ Misses 170 154 -16
+ Partials 70 63 -7
Impacted Files | Coverage Δ | |
---|---|---|
trio_asyncio/__init__.py | 100.00% <ø> (ø) |
|
trio_asyncio/_loop.py | 79.32% <50.00%> (+0.63%) |
:arrow_up: |
trio_asyncio/_adapter.py | 81.19% <100.00%> (+1.03%) |
:arrow_up: |
trio_asyncio/_base.py | 84.14% <100.00%> (-0.64%) |
:arrow_down: |
trio_asyncio/_util.py | 84.09% <100.00%> (ø) |
|
trio_asyncio/_version.py | 100.00% <100.00%> (ø) |
|
trio_asyncio/_deprecate.py | 100.00% <0.00%> (+19.44%) |
:arrow_up: |
@smurfix Thank you! I considered doing this change myself, but I thought it would make trio-asyncio
Python 3.8+ only. Test results are proving me wrong :)
Code coverage got lower. Most of it is due to _deprecate
module. We use much less of it now, due to removed deprecations. Options (ordered by increasing difficulty):
test_deprecate
from Trio and adapt it (easiest)_deprecate
module_deprecate
to its own package and use it in both trio
and trio-asyncio
Update: I did port test_deprecate
from Trio and codecov is finally happy. 👇
@oremanj:
I just uploaded #96 which appears to fix it. Probably worth incorporating into the release?
Awesome, thank you! Yes, let's postpone the release until we get #96 merged.
(In the mean time, I've made the fixes you suggested.)
This LGTM. I merged #96 so once you incorporate that (and #99 maybe?) I think it's ready.
Interesting that this PR hasn't had any of the problems that the Mac builds have been having on other PRs. Those all seem to have failed around test_cancel_sleep_depr
in test_misc.py
, which is now gone. But I can't for the life of me figure out why test_cancel_sleep_depr
would hang if the equivalent test_cancel_sleep
works fine. Gremlins!
@oremanj Now it did stuck at test_cancel_sleep
. And I did find a way to replicate the issue locally. Issue coming soon!
Update: here is the issue - #103. Should we fix this deadlock before the release? Opinions?
"Fixed" the #103 deadlock in test_cancel_sleep
by removing unnecessary raise Exception
. The test would now fail with AssertionError
rather than deadlock. I've also fiddled with timeout length to lower failure probability: 970d81c.
I think the underlying cause of deadlock is #104. No need to fix it for this release, because the problem was in v0.11.0 as well.
Release notes screenshot
TODO
xfail
ed test (fixed by #96)test_asyncio_trio_adapted_no_loop
to something elsehistory.rst
history.rst
+dev
tag to the endFixes #93