This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gvanrossum
Recipients gvanrossum, j1m, vstinner, yselivanov
Date 2016-06-29.18:15:43
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Hm. The docs in PEP 3156 do mention that create_connection() is for clients (though it weakens this with "typically"):

I always think of TCP connections (which is what create_connection() is about) as essentially asymmetrical -- the server uses bind() and listen() and then sits in an accept() loop accepting connections, while the client reaches out to the server using connect(). And create_connection() is a wrapper around that connect() call; for servers we have create_server(). (The asymmetry in naming reflects the asymmetry in functionality and API.)

You can pass a pre-connected socket in to create_connection() for edge cases where you need control over how the socket is created and initialized or when there's a 3rd party library that can give you a connected socket that you want/need to use. Similarly, you can pass a pre-bound socket to create_server().

I guess at the lower, TCP level, there isn't much of a difference between a client-side socket and the kind of server-side socket that's returned by accept(). And maybe that's also the case for SSL (I've never actually understood most of the details of using SSL).

Maybe it's just culture shock? Or maybe we just need a public API that roughly represents the pair of calls to _make_ssl_transport() and _make_socket_transport() that are currently appearing both in _create_connection_transport() and in _accept_connection2(), plus some of the code around it that's a little tricky?
Date User Action Args
2016-06-29 18:15:43gvanrossumsetrecipients: + gvanrossum, vstinner, j1m, yselivanov
2016-06-29 18:15:43gvanrossumsetmessageid: <>
2016-06-29 18:15:43gvanrossumlinkissue27392 messages
2016-06-29 18:15:43gvanrossumcreate