[issue22252] ssl blocking IO errors should inherit BlockingIOError

Christian Heimes added the comment: I agree with Antoine, let's not subclass io.BlockingIOError. -- resolution: -> wont fix status: open -> closed ___ Python tracker ___ ___

[issue22252] ssl blocking IO errors should inherit BlockingIOError

Changes by Martin Panter : -- nosy: +vadmium title: ssl blocking IO errors -> ssl blocking IO errors should inherit BlockingIOError ___ Python tracker ___ __

[issue22252] ssl blocking IO errors

Antoine Pitrou added the comment: Le 23/08/2014 03:02, Hristo Venev a écrit : > When will SSLSocket.recv() raise SSLWantWriteError? > When will SSLSocket.send() raise SSLWantReadError? > > According to my very basic knowledge abou the protocol, this will never > happen. According to the OpenSSL

[issue22252] ssl blocking IO errors

Hristo Venev added the comment: My questions are: When will SSLSocket.recv() raise SSLWantWriteError? When will SSLSocket.send() raise SSLWantReadError? According to my very basic knowledge abou the protocol, this will never happen. -- ___ Python tra

[issue22252] ssl blocking IO errors

Antoine Pitrou added the comment: > ssl.SSLWantReadError and ssl.SSLWantWriteError should inherit > io.BlockingIOError. > Generic code that works with non-blocking sockets will stop working with > SSLSockets. I'll have to think about that, but in any case non-blocking SSL code needs to be sub

[issue22252] ssl blocking IO errors

New submission from Hristo Venev: ssl.SSLWantReadError and ssl.SSLWantWriteError should inherit io.BlockingIOError. Generic code that works with non-blocking sockets will stop working with SSLSockets. Does anybody have any idea if SSLSocket.read() will need to write to the underlying socket