[issue29344] sock_recv not detected a coroutine

Yury Selivanov added the comment: They have been documented as coroutines and were returning futures since Python 3.4. I believe we can keep the status quo especially if only one user complained about it during the last 5 years. --

[issue29344] sock_recv not detected a coroutine

Berker Peksag added the comment: Well, the current status quo has already confused a user (see msg286011) > (so that people don't write code that expects them to be not coroutines in > 3.6) Even if people expect these methods to be coroutines, two functions of the

[issue29344] sock_recv not detected a coroutine

Yury Selivanov added the comment: Since we made them coroutines in 3.7, I'd prefer to keep the 3.6 documentation as is (so that people don't write code that expects them to be not coroutines in 3.6). Please let's keep the current status quo. --

[issue29344] sock_recv not detected a coroutine

Berker Peksag added the comment: > We only fixed it in 3.7 and the doc was updated. 3.6 stays as is. I'm not talking about fixing code in 3.6. In 3.6, sock_* methods still documented as coroutines but they are normal functions: *

[issue29344] sock_recv not detected a coroutine

Berker Peksag added the comment: Andrew, shouldn't we fix 3.6 documentation? sock_* methods still documented as coroutines. -- ___ Python tracker

[issue29344] sock_recv not detected a coroutine

Yury Selivanov added the comment: > Andrew, shouldn't we fix 3.6 documentation? sock_* methods still documented > as coroutines. We only fixed it in 3.7 and the doc was updated. 3.6 stays as is. -- ___ Python tracker

[issue29344] sock_recv not detected a coroutine

Andrew Svetlov added the comment: sock_recv was converted into genuine coroutine in Python 3.7 Closing the issue. -- nosy: +asvetlov resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -Python 3.5, Python 3.6

[issue29344] sock_recv not detected a coroutine

Guido van Rossum added the comment: A new Sphinx declaration sounds great to me, but you might want to check with some Sphinx or Python-docs expert. I somehow misread the code of IocpProactor.connect(), so ignore that part -- the point is that it's not always a coroutine. --

[issue29344] sock_recv not detected a coroutine

Yury Selivanov added the comment: > Maybe we should switch all these to "awaitable"? I like this! Would it be OK to add a new sphinx declaration? So that: .. coroutinemethod:: AbstractEventLoop.shutdown_asyncgens() would become: .. awaitable:: AbstractEventLoop.shutdown_asyncgens()

[issue29344] sock_recv not detected a coroutine

Guido van Rossum added the comment: The word coroutine has a more specific meaning though (and we have iscoroutine*() inspection functions to check for it). Maybe we should switch all these to "awaitable"? Also note that in proactor_events.py, sock_connect() is *not* a coroutine. In fact I'm

[issue29344] sock_recv not detected a coroutine

Yury Selivanov added the comment: I think the original idea was to document that all methods of the loop are coroutines, so that: 1. if a user needs a Future object they call ensure_future: fut = asyncio.ensure_future(loop.method()) 2. it gives us ability to refactor things. For

[issue29344] sock_recv not detected a coroutine

Berker Peksag added the comment: Here's a patch. sock_connect() wrapped by @coroutine in Lib/asyncio/selector_events.py so I left it as-is. Let me know if it still needs to be updated: @coroutine def sock_connect(self, sock, address): """Connect to a remote socket at address.

[issue29344] sock_recv not detected a coroutine

Guido van Rossum added the comment: OP is correct. sock_recv(), sock_sendall(), sock_connect(), sock_accept() all are functions that return Futures. The docs are wrong, as are the docstrings in the code. -- versions: +Python 3.5, Python 3.7 ___

[issue29344] sock_recv not detected a coroutine

Berker Peksag added the comment: I'm not really familiar with asyncio terminology, but it looks like it returns a future: >>> asyncio.isfuture(loop.sock_recv(sock, 1024)) True There is a also a test in test_selector_events: f = self.loop.sock_recv(sock, 1024)

[issue29344] sock_recv not detected a coroutine

New submission from Jeremy Bustamante: Documemtation says sock_recv is a coroutine https://docs.python.org/3.6/library/asyncio-eventloop.html#low-level-socket-operations But following code says it isnt: import asyncio loop = asyncio.get_event_loop() asyncio.iscoroutinefunction(loop.sock_recv)