New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add asyncio (tulip, PEP 3156) to stdlib #63461
Comments
I'll add the tests next. The plan is to get this in the next (last) alpha release. |
It will probably need some messaging to integrate the Windows overlapped stuff? |
(massaging, probably) |
If you need help with docs, let me know. |
Here's an updated patch that doesn't botch the selectors imports. |
What I need help with most right now is a suggestion of where the unittests should go. There are too many of them to all put in one file. Some options: asyncio/test/test.py What's the best current practice? (I also want to add some hacks so that the files can actually be identical in the stdlib and in the separate 3rd party repo, otherwise keeping the two in sync will be too much work.) |
Personally I have a preference for test/test_asyncio/test_*.py, because However, other packages such as unittest have their dedicated test As for test_.py vs. *test.py, test.py is definitely the norm in the |
OK, here's a new patch that includes tests. To run the tests, I use: ./python.exe Lib/test/regrtest.py --fromfile Lib/test/test_asyncio/tests.txt --verbose There are a total of 4 individual test failures, all having to do with SSL: ssl.SSLEOFError: EOF occurred in violation of protocol (_ssl.c:589) Did anything change in the ssl module recently? |
Found the cause of the ssl test failure -- the location of the ssl test key and cert are different. Here's a new patch with a quick fix (#4), but I think the correct solution is to either have the certificates inline in the source and write them to a temp file, or move them into the main asyncio library, or move the test_utils.py module -- since the test files are referenced from test_utils.py they should be in the same directory. Preferences? There are still some test failures, the Windows tests are being run everywhere. I'll look into how to do that later. |
You could simply reuse Lib/test/keycert.pem (when in stdlib mode). |
Turns out there were other uses of the sample key/cert pair. The easiest solution is to just have the code try both locations if necessary. Here's a new patch to review. |
Here's a partial patch for Windows. (Mostly for myself; I need to integrate this into the main patch.) |
Here's a full new patch, with Windows project/solution changes included, and updated from the latest Tulip asyncio branch. |
PS. There's some garbage at the start of pcbuild.sln (perhaps a BOM mark?). I'm not going to re-upload the patch for now, but please note this. |
New patch, mostly SSL hardening IIRC. |
I could use some help for two issues with the tests: (1) How do I stop regrtest.py from running the windows tests? (These import _winapi.) (2) I get this message -- what does it mean and should I care? |
@unittest.skipIf(sys.platform == "win32", "Does not apply to Windows") |
|
On 16/10/2013 8:14pm, Guido van Rossum wrote:
Perhaps threads from the ThreadExecutor are still alive when those tests |
I'd have to decorate a lot of tests. Is there a way to fix this at the module or at least class level? (I'd be willing to move the imports around.) |
I think at module level you can do if sys.platform != 'win32':
raise unittest.SkipTest('Windows only') |
Yup, that works! Not uploading a new patch right now but this is in the tulip repo now. |
You can skip classes with skipIf as a class decorator. |
Another day, another patch. I'd rather like to commit this (and then iterate as needed), it makes my workflow for porting to Windows a little easier. Larry??? |
Does it break anything? (Besides, possibly, itself?) |
It doesn't break anything AFAICT. (It's a pure addition except for one new However I just discovered that apparently regrtest doesn't automatically On Thu, Oct 17, 2013 at 12:59 PM, Larry Hastings <report@bugs.python.org>wrote:
|
If its breakage is restricted to itself (and its tests) then you have my blessing to check it in. (Sorry, can't help you with the test expertise.) |
OK, no more giant patches. It's checked in. I've also solved the regrtest issues by adding some code in __init__.py and __main__.py. I expect to iterate a bit over the next few days. |
New changeset 30f33e6a04c1 by Ned Deily in branch 'default': |
There are 5 unique test failures that have come up in the koobs-freebsd* buildbots post the test_asyncio import. Would we prefer to create a meta issue to track them, or put them here? |
Summary of 4 test failures below, will attach the complete buildbot logs for detail. ====================================================================== Traceback (most recent call last):
File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/test_asyncio/test_events.py", line 241, in test_call_later
self.assertTrue(0.09 <= t1-t0 <= 0.12, t1-t0)
AssertionError: False is not true : 0.12008954107295722 ====================================================================== Traceback (most recent call last):
File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/test_asyncio/test_events.py", line 468, in test_signal_handling_args
self.assertEqual(caught, 1)
AssertionError: 0 != 1 ====================================================================== Traceback (most recent call last):
File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/test_asyncio/test_events.py", line 626, in test_create_server_ssl
self.assertEqual(3, proto.nbytes)
AssertionError: 3 != 0 ====================================================================== |
> Traceback (most recent call last):
> File
> "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/test_asyncio/test_events.py",
> line 241, in test_call_later
> self.assertTrue(0.09 <= t1-t0 <= 0.12, t1-t0)
> AssertionError: False is not true : 0.12008954107295722 This one is a classical timing issue. The test is too optimistic: (e.g. call_later with 0.5 and check that the resulting delay |
@koobs: I'll look into these, but in the future it's better to report bugs "upstream" for now, i.e. at http://code.google.com/p/tulip/ -- they will get my immediate attention. @antoine: while most of the timing-related tests use a simulated clock, there are still some that must use real time. I'll fix them as needed. |
I fixed the easy one (the expected delay in test_call_later). I could use some hands with the rest -- I suspect there are similar race conditions. I'm tracking this now in http://code.google.com/p/tulip/issues/detail?id=75 |
The --without-threads buildbot fails, so I guess all tests need to be |
Maybe adding something that returns [] from suite() if therea re no threads in test/test_asyncio/init.py would help? I don't have time to test this, but go ahead and commit something if it's a release blocker. Even better would or course be to fix asyncio to actually work if there are no threads -- the only issue is what to do about run_in_executor(), I guess it will have to run the function in-line... |
AIX buildbot is experiencing a similar failure: [276/382/4] test_asyncio |
@guido, another expected delay test failure: ====================================================================== Traceback (most recent call last):
File "/usr/home/buildbot/python/3.x.koobs-freebsd9/build/Lib/test/test_asyncio/test_events.py", line 218, in test_run_until_complete
self.assertTrue(0.08 <= t1-t0 <= 0.12, t1-t0)
AssertionError: False is not true : 0.12018337799236178 Note: Also referenced "upstream" :] |
Relaxed a bunch of timeouts. No news on the --without-threads case, that |
I've landed a bunch of stuff, and now I am pretty happy. It's also soon going to be weekend, which means family time, so I really hope everyone else is also happy. :-) A summary of what changed since the initial asyncio checkin:
And in the tests:
|
Ready for release! |
2013/10/19 Guido van Rossum <report@bugs.python.org>:
The new module has no documentation at all. Do you plan to open a new |
I'll track that separately: http://bugs.python.org/issue19291 For now, PEP-3156 has a lot of information. (But the PEP also needs to be updated to track recent developments.) |
How is this ready for release? The patch does not work on numerous POSIX systems. |
Please be more specific. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: