Christian Heimes added the comment:
Yury, I don't remember how I found the issue.
It's still an issue in 3.9 and newer.
--
versions: +Python 3.10, Python 3.11, Python 3.9 -Python 3.6, Python 3.7
___
Python tracker
Yury Selivanov added the comment:
Christian, how did you find this (i.e. what module/package is broken because of
this)? I'm still not entirely sure that raising EBADF in socket.close() is a
good thing.
--
nosy: +yselivanov
___
Python tracker
Charles-François Natali added the comment:
FWIW I agree with Antoine and Martin: ignoring EBADF is a bad idea,
quite dangerous.
The man page probably says this to highlight that users shouldn't
*retry* close():
"""
Retrying the close() after a failure return is the wrong thing to do,
Martin Panter added the comment:
I added this behaviour in 3.6 on purpose via Issue 26685.
The change also impacted Yury (see the original bug thread), but if I
understood correctly, he eventually decided that it highlighted a problem in
asyncio or his code (though the resulting asyncio pull
Antoine Pitrou added the comment:
Closing a socket whose fd has already been closed before is a bug waiting to
happen. Indeed it feels harmless if you just get a EBADF, but if the given fd
gets reused in the meantime for another file or socket, your close() method is
going to close a
New submission from Christian Heimes:
In Python 3.6 the behavior of socket's close method has changed. In Python 2.7,
3.5 and earlier, socket.close() ignored EBADF. Starting with Python 3.6
socket.close() raises an OSError exception when its internal fd has been closed.
Python 2.7.12
