[issue25749] asyncio.Server class documented but not exported

Ron Frederick added the comment: > I think you're doing it the right way. It's a rather niche requirement, so I > don't think we should make create_server to somehow support this use case. Agreed. > asyncssh looks absolutely amazing, btw. Thanks so much! --

[issue25749] asyncio.Server class documented but not exported

Yury Selivanov added the comment: > It did mean duplicating a handful of lines of code from asyncio to iterate > over the getaddrinfo() results (creating one asyncio.Server per sockaddr > instead of letting asyncio create a single asyncio.Server with multiple >

[issue25749] asyncio.Server class documented but not exported

Ron Frederick added the comment: That'd be great if you could add AbstractServer to the 3.7 docs - thanks! Regarding the other issue, I'm already set up to use multiple asyncio.Server objects to deal with the shared port issue and it's working fine. It did mean

[issue25749] asyncio.Server class documented but not exported

Yury Selivanov added the comment: > _OR_ adding AbstractServer to the documentation and changing existing > references to asyncio.Server to point at asyncio.AbstractServer instead, as > that symbol is already exported but is not currently documented. I completely

[issue25749] asyncio.Server class documented but not exported

Yury Selivanov added the comment: > I'm really not sure there's ANY call other than getsockaddr() that really > makes sense here, though, so perhaps it would be better to evolve the API in > AbstractServer into returning a list of sockaddr tuples rather than sockets.

[issue25749] asyncio.Server class documented but not exported

Ron Frederick added the comment: Thanks. Unfortunately, in the case of the way SSH listeners with dynamic ports, the protocol only allows a single port number to be returned. So, when binding on multiple interfaces there's a requirement that the SAME port be chosen for

[issue25749] asyncio.Server class documented but not exported

Yury Selivanov added the comment: Server.sockets property will be a public API and defined in the AbstractServer, so you can start using them. Just don't try to call socket.send() or socket.accept() as that will break things. --

[issue25749] asyncio.Server class documented but not exported

Ron Frederick added the comment: In my original report, I suggested _either_ exporting asyncio.Server since that's what was documented elsewhere _OR_ adding AbstractServer to the documentation and changing existing references to asyncio.Server to point at

[issue25749] asyncio.Server class documented but not exported

Yury Selivanov added the comment: There's no point in exporting the Server class as "asyncio.Server". It'd created and managed by the event loop, and there's no point to instantiate it in user code. We can add an abstract base class AbstractServer though, similar to

[issue25749] asyncio.Server class documented but not exported

Change by Andrew Svetlov : -- versions: +Python 3.7 -Python 3.4, Python 3.5 ___ Python tracker ___

[issue25749] asyncio.Server class documented but not exported

Change by Andrew Svetlov : -- assignee: -> asvetlov nosy: +asvetlov ___ Python tracker ___

[issue25749] asyncio.Server class documented but not exported

New submission from Ron Frederick: The asyncio documentation defines the class 'asyncio.Server' in section 18.5.1.15. However, this class is not exported by asyncio. It is defined in base_events.py but not in the __all__ list. The only class exported at the asyncio top level is

[issue25749] asyncio.Server class documented but not exported

Yury Selivanov added the comment: Let's not export the Server class -- in uvloop, for instance, I have a completely different internal implementation of Server (I can't use the one from asyncio). -- ___ Python tracker

[issue25749] asyncio.Server class documented but not exported

STINNER Victor added the comment: Yury Selivanov added the comment: > But Ron suggested to actually export the Server class, so that it's available > as 'asyncio.Server'. And I think that *that* is a bad idea, (...) I know, but IMHO the issue is wider than just exporting or not the symbol.

[issue25749] asyncio.Server class documented but not exported

STINNER Victor added the comment: Yeah, I recall this point. The doc points to Server, but Guido didn't want to expose "implementation details" of Server like sockets. Different implementations of event loops (Yury gave the good example of uvloop based on libuv) don't give (direct) access to

[issue25749] asyncio.Server class documented but not exported

Yury Selivanov added the comment: > Yeah, I recall this point. The doc points to Server, but Guido didn't want to expose "implementation details" of Server like sockets. Different implementations of event loops (Yury gave the good example of uvloop based on libuv) don't give (direct) access to