SSLSocket.send() for non-blocking sockets

Hello, I'd like to hear some more opinions on http://bugs.python.org/issue20951. I think the possible courses of action are: 1. Document the current behavior. This has the drawback that (a) it still remains rather counterintuitive, and (b) one still needs extra code to distinguish between a zero-return because the write would block, and a zero-return because the peer has closed the connection. I'm not sure about the best way to do this check. I would probably try to run select() on the underlying raw socket. Is there a better way? 2. Change the behavior immediately, potentially breaking some applications that worked around it, but unbreaking others that relied on the documented behavior. 3. Deprecate the current behavior, and introduce a transition period where the new behavior is controlled by a flag. Drawbacks: no direct breakage of anything, but additional complexity may indirectly cause bugs. Thoughts? Best, -Nikolaus -- Encrypted emails preferred. PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C »Time flies like an arrow, fruit flies like a Banana.«

On Wed, Mar 26, 2014 at 11:54 AM, Nikolaus Rath <Nikolaus@rath.org> wrote:
2. Change the behavior immediately, potentially breaking some applications that worked around it, but unbreaking others that relied on the documented behavior.
If it's a functionality change that's likely to break code, would it be worth changing it only in 3.5, and documenting it as broken in 3.4 and earlier? ChrisA

Chris Angelico <rosuav@gmail.com> writes:
On Wed, Mar 26, 2014 at 11:54 AM, Nikolaus Rath <Nikolaus@rath.org> wrote:
2. Change the behavior immediately, potentially breaking some applications that worked around it, but unbreaking others that relied on the documented behavior.
If it's a functionality change that's likely to break code, would it be worth changing it only in 3.5, and documenting it as broken in 3.4 and earlier?
Yes, that's what I meant. I don't think changing it in 3.4 is an option at all. Best, -Nikolaus -- Encrypted emails preferred. PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C »Time flies like an arrow, fruit flies like a Banana.«
participants (2)
-
Chris Angelico
-
Nikolaus Rath