Antoine Pitrou <pit...@free.fr> added the comment: > Depends on what we want. It just suppresses information that's now > available. What we'd really like is for the caller to recognize that > close() can fail, and should be re-tried if it does. That requires > that we signal the error back up and out of the ssl module. It seems > to me that any non-blocking code should recognize this and respect it.
Well, first, it will break code which used to work perfectly well (as the failing tests show). That OpenSSL decided to break compatibility in what looks like a minor bugfix release (0.9.8m) doesn't mean we should propagate the breakage. Second, I'm not an SSL expert, but it's not obvious to me that the application should have to ensure a "complete shutdown" before closing the socket. Often, stateful applicative protocols close their "session" anyway (*) before shutting down the transport layer, so I don't see what this additional precaution can buy (apart from code complication). (*) for example, FTP has the "QUIT" command ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue8108> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
