[issue38529] Python 3.8 improperly warns about closing properly closed streams
Ron Frederick added the comment: Sorry, I should have said that the change below was in the file asyncio/streams.py. -- ___ Python tracker <https://bugs.python.org/issue38529> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38529] Python 3.8 improperly warns about closing properly closed streams
Ron Frederick added the comment:
I think the following change might address this problem:
***
*** 233,239
def _on_reader_gc(self, wr):
transport = self._transport
! if transport is not None:
# connection_made was called
context = {
'message': ('An open stream object is being garbage '
--- 233,239
def _on_reader_gc(self, wr):
transport = self._transport
! if transport is not None and not transport.is_closing():
# connection_made was called
context = {
'message': ('An open stream object is being garbage '
--
___
Python tracker
<https://bugs.python.org/issue38529>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38529] Python 3.8 improperly warns about closing properly closed streams
New submission from Ron Frederick :
In testing AsyncSSH against Python 3.8, I noticed a large number of the
following errors, even though I was properly closing streams before the objects
holding them were garbage-collected.
An open stream object is being garbage collected; call "stream.close()"
explicitly.
After some investigation, the problem appears to be that closing a stream is
not good enough to prevent the error. The check in asyncio doesn't properly
handle the case where the stream is closing, but has not fully closed. Here's a
simple test program that demonstrates this:
import asyncio
async def tcp_client():
reader, writer = await asyncio.open_connection('127.0.0.1', 22)
writer.close()
asyncio.run(tcp_client())
It's possible to avoid this message by awaiting on writer.wait_closed(), but
wait_closed() doesn't exist until Python 3.7, making it very difficult to write
portable code and still avoid this message.
--
components: asyncio
messages: 354953
nosy: Ron Frederick, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: Python 3.8 improperly warns about closing properly closed streams
type: behavior
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue38529>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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! -- ___ Python tracker <https://bugs.python.org/issue25749> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 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 listening sockets) and there are some other minor details like cleaning up if the kernel-selected dynamic port chosen for the first interface is not actually free on all other interfaces, but I'm not actually looking for any changes in how that's working right now. Here's the code I'm referring to if you're curious: https://github.com/ronf/asyncssh/blob/master/asyncssh/listener.py#L192 -- ___ Python tracker <https://bugs.python.org/issue25749> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 all of the socket bindings, which can't easily be done today with a single asyncio.Server object. That's a bit off-topic for this issue, though. Regarding exposing the sockets, it would never really make sense to directly call send() on a listening socket, and I can see why it also wouldn't make sense to allow calling accept(). 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. -- ___ Python tracker <https://bugs.python.org/issue25749> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 asyncio.AbstractServer instead, as that symbol is already exported but is not currently documented. There appear to be good reasons for hiding the implementation details of Server, and I'm good with that. I just think the docs and the exports need to agree on one or the other. I originally had references to AbstractServer in my project docs, but changed them to Server after seeing that only Server was currently in the public Python documentation. As for references to the "sockets" member of Server, I'm not currently relying on that in my code. I have code that can handle getaddrinfo() returning more than one address to listen on, but I create separate Server instances for each individual address right now, as this gives me better control when a caller asks to listen on a dynamic port on multiple interfaces at once. -- ___ Python tracker <https://bugs.python.org/issue25749> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 asyncio.AbstractServer, defined in events.py. I think the documentation should match the exports. Either Server should be exported out of base_events.py, or the documentation should only refer to asyncio.AbstractServer. -- components: asyncio messages: 255476 nosy: Ron Frederick, gvanrossum, haypo, yselivanov priority: normal severity: normal status: open title: asyncio.Server class documented but not exported type: behavior versions: Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <http://bugs.python.org/issue25749> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
