Repository navigation
Add socket.getblocking() method #76554
Description
| BPO | 32373 |
|---|---|
| Nosy | @pitrou, @vstinner, @njsmith, @asvetlov, @1st1 |
| PRs |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee = 'https://github.com/1st1'
closed_at = <Date 2018-01-28.23:18:40.694>
created_at = <Date 2017-12-19.14:23:24.198>
labels = ['3.7', 'type-feature', 'library']
title = 'Add socket.getblocking() method'
updated_at = <Date 2018-01-28.23:18:40.693>
user = 'https://github.com/1st1'bugs.python.org fields:
activity = <Date 2018-01-28.23:18:40.693>
actor = 'yselivanov'
assignee = 'yselivanov'
closed = True
closed_date = <Date 2018-01-28.23:18:40.694>
closer = 'yselivanov'
components = ['Library (Lib)']
creation = <Date 2017-12-19.14:23:24.198>
creator = 'yselivanov'
dependencies = []
files = []
hgrepos = []
issue_num = 32373
keywords = ['patch']
message_count = 6.0
messages = ['308645', '308656', '308658', '308663', '308693', '311019']
nosy_count = 5.0
nosy_names = ['pitrou', 'vstinner', 'njs', 'asvetlov', 'yselivanov']
pr_nums = ['4926']
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'enhancement'
url = 'https://bugs.python.org/issue32373'
versions = ['Python 3.7']
Activity
1st1 commentedon Dec 19, 2017
Currently we have the following methods:
socket.gettimeout() is the only easy way of checking if the socket is non-blocking or blocking, but it's not intuitive to use it. It's especially strange that we have a setblocking() method without a corresponding getblocking().
I propose to add a 'socket.getblocking() -> bool' method.
1st1 commentedon Dec 19, 2017
It looks like we have a bug with 'sock.settimeout()' and non-blocking/blocking modes (or maybe this is a feature?)
Currently:
to make a socket non-blocking, we call 'sock.settimeout(0)'.
to make a socket blocking, we call 'sock.settimeout(None)'.
What happens if we call sock.settimeout(t), where t > 0? The internal timeout field of the socket object will simply be set to 't'. What happens if the socket was in a non-blocking mode? Nothing, it stays in non-blocking mode.
What it means: suppose you have a non-blocking socket. You call socket.settimeout(10), and most likely you wanted to make it blocking again. Because all operations on the socket become blocking from moment (sock_call_ex repeats on EWOULDBLOCK and EAGAIN).
Now is having a timeout and blocking send/recv methods on a non-blocking socket a feature? Or is this a bug?
pitrou commentedon Dec 19, 2017
I agree it's a bug (but should only be fixed in 3.7).
Also I agree with adding a socket.getblocking() method.
asvetlov commentedon Dec 19, 2017
Agree, it's a bug.
+1 for getblocking()
1st1 commentedon Dec 19, 2017
It appears the the timeouts situation is a bit more complex. It's perfectly normal for a Python socket object to be in a "blocking" mode and for its FD to be in a non-blocking mode. Read more about this in the latest docs update to the PR: adcc91f
1st1 commentedon Jan 28, 2018
New changeset f11b460 by Yury Selivanov in branch 'master':
bpo-32373: Add socket.getblocking() method. (bpo-4926)
f11b460