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
asyncio/test/test_*.py
test/test_asyncio/<either of the above>

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.)

> asyncio/test/*_test.py
> asyncio/test/test_*.py
> test/test_asyncio/<either of the above>

Personally I have a preference for test/test_asyncio/test_*.py, because
putting all tests in test/ makes them easier to find.

However, other packages such as unittest have their dedicated test
packages (unittest/test/...).

As for test_*.py vs. *_test.py, test_*.py is definitely the norm in the
source tree.

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.

> 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?

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 tests failed:
    test_asyncio.test_windows_events test_asyncio.test_windows_utils


(2) I get this message -- what does it mean and should I care?
2 tests altered the execution environment:
    test_asyncio.test_base_events test_asyncio.test_futures

1) The test case decorator perhaps:

@unittest.skipIf(sys.platform == "win32", "Does not apply to Windows")

2) See class saved_test_environment in regrtest.py.  I wouldn't worry too much about it initially but it should be looked at and tidied up before release.

On 16/10/2013 8:14pm, Guido van Rossum wrote:
> (2) I get this message -- what does it mean and should I care?
> 2 tests altered the execution environment:
>      test_asyncio.test_base_events test_asyncio.test_futures

Perhaps threads from the ThreadExecutor are still alive when those tests 
finish.

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
extension module on Windows).

However I just discovered that apparently regrtest doesn't automatically
run tests in a subdirectory of the test package. I'm guessing I'll need to
add some magic to test_asyncio/__init__.py. Any hints?

On Thu, Oct 17, 2013 at 12:59 PM, Larry Hastings <report@bugs.python.org>wrote:

>
> Larry Hastings added the comment:
>
> Does it break anything?  (Besides, possibly, itself?)
>
> ----------
>
> _______________________________________
> Python tracker <report@bugs.python.org>
> <http://bugs.python.org/issue19262>
> _______________________________________
>

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':
Issue #19262: Install asyncio and test_asyncio directories.
http://hg.python.org/cpython/rev/30f33e6a04c1

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.

======================================================================
FAIL: test_call_later (test.test_asyncio.test_events.SelectEventLoopTests)
----------------------------------------------------------------------
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

======================================================================
FAIL: test_signal_handling_args (test.test_asyncio.test_events.SelectEventLoopTests)
----------------------------------------------------------------------
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

======================================================================
FAIL: test_create_server_ssl (test.test_asyncio.test_events.KqueueEventLoopTests)
----------------------------------------------------------------------
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


======================================================================
Timeout (1:00:00)!
<snip>
Exception: Child error on test_asyncio: Exit code 1
----------------------------------------------------------------------

> ======================================================================
> FAIL: test_call_later
> (test.test_asyncio.test_events.SelectEventLoopTests)
> ----------------------------------------------------------------------
> 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:
many buildbots can be quite slow or loaded. Other timing tests in the
stdlib allow for much more slack.

(e.g. call_later with 0.5 and check that the resulting delay
is between 0.4 and 1.0)

@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
skipped in that case:

http://buildbot.python.org/all/builders/AMD64%20Fedora%20without%20threads%203.x/builds/5333/steps/test/logs/stdio

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
Timeout (1:00:00)!
Thread 0x00000001:
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/selectors.py", line 265 in select
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/asyncio/base_events.py", line 576 in _run_once
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/asyncio/base_events.py", line 153 in run_forever
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/asyncio/base_events.py", line 172 in run_until_complete
  File "/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/test/test_asyncio/test_events.py", line 1012 in test_subprocess_interactive

@Guido, another expected delay test failure:

======================================================================
FAIL: test_run_until_complete (test.test_asyncio.test_events.KqueueEventLoopTests)
----------------------------------------------------------------------
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
will have to happen post-alpha-4 I expect.

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:

- Rename the logger to plain "logger".
- Rename Transport.pause/resume to pause_reading/pause_writing.
- Important race condition fix.
- Write flow control for asyncio! (And asyncio/streams.py overhaul.)

And in the tests:

- Make the tests run on Windows.
- Relax various test timeouts to reduce flakiness on slow buildbots.

Ready for release!

2013/10/19 Guido van Rossum <report@bugs.python.org>:
> Ready for release!
>
> resolution:  -> fixed
> status: open -> closed

The new module has no documentation at all. Do you plan to open a new
issue for the documentation? Or maybe you don't plan to add
documentation? :-)

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.