I don't like the name -- how about wrap_socket()?

wrap_socket implies that it's for wrapping client or server sockets, but it's not. It's only for handling server sockets. Also, I prefer a name that reflects goal, not mechanism.

I think the name should be discussed over here: https://bugs.python.org/issue27392.

What's wrong with the Python 3.4 tests on Windows (AppVeyor)?

Can we share more code between this and _create_connection_transport()?

I'll deliberate the name in the Python tracker issue.

I have no idea WRT Python 3.4 on windows. It seems to be hanging. I don't have a windows development environment. Do you by any chance know where I can find a good howto for setting one up?

Just a note WRT the name: Really it's about more than the name. @1st1 argues that there should be a new API for wrapping already-connected sockets, for both clients and servers, and that create_connection shouldn't accept connected sockets. I think this is a pretty good argument.

WRT sharing code, I guess I could make _create_connection_transport handle both the client and server case. I'll do that.

OK, more sharing. Maybe I'll be lucky and the windows tests will pass. :)

Aside from a couple of nits it looks good.

The tests hanging for the ProactorEventLoop with SSL. I'll skip that case.

BTW, running tests verbosely is helpful for cases like this. Is there any harm in always running the appveyor tests verbosely?

The tests hanging for the ProactorEventLoop with SSL. I'll skip that case.

Strange, sounds like we need to open an issue for this (but it shouldn't block this PR).

BTW, running tests verbosely is helpful for cases like this. Is there any harm in always running the appveyor tests verbosely?

Yes, it makes sense. Can you make a separate PR to run tests in verbose mode both for Travis and AppVeyor?

The tests hanging for the ProactorEventLoop with SSL. I'll skip that case.

Strange, sounds like we need to open an issue for this (but it shouldn't
block this PR).

No, It's documented:
https://docs.python.org/3/library/asyncio-eventloops.html#windows

BTW, running tests verbosely is helpful for cases like this. Is there any
harm in always running the appveyor tests verbosely?

Yes, it makes sense. Can you make a separate PR to run tests in verbose
mode both for Travis and AppVeyor?

Sure.

Jim

Jim Fulton
http://jimfulton.info

OK, all tests passing. Assuming this is merged, I'll update the docs. Where do I do that?

LGTM. Will merge it in a few hours.

OK, all tests passing. Assuming this is merged, I'll update the docs. Where do I do that?

@gvanrossum Should we copy asyncio docs from CPython to this repo and update the update_stdlib.sh script to handle that?

Can this be merged? If it is, will it be in 3.6? I'm happy to update the docs wherever.

Can this be merged? If it is, will it be in 3.6? I'm happy to update the docs wherever.

Merged. Yes, it will be in 3.6 (and I'll add it to uvloop in a couple of days).

For the docs please upload a patch to https://bugs.python.org/issue27392.

@gvanrossum

I think it may be time actually to give up on this github repo and focus
all development in the CPython repo. Especially since I also think that
asyncio should drop the "provisional" status in Python 3.6.

Please let's wait until CPython migrates to GitHub. I like code review workflow here much better.