[issue1291446] SSLObject breaks read semantics
Jonathan Ellis <[EMAIL PROTECTED]> added the comment: This is incorrect. Perhaps you are thinking of a raw socket read; a _file-like-object_ read is supposed to return the amount of data requested, unless (a) the socket is in non-blocking mode, or (b) if EOF is reached first. Normal socket.makefile observes this, but SSLObject does not. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1291446> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1291446] SSLObject breaks read semantics
Jonathan Ellis <[EMAIL PROTECTED]> added the comment: s/raw socket read/raw socket recv/ ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1291446> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1291446] SSLObject breaks read semantics
Jonathan Ellis <[EMAIL PROTECTED]> added the comment: Here is the exact SSLObject.read documentation from 2.5 (although the bug was filed against 2.4, and 2.6 will be out soon, the docs are the same): - read([n]) If n is provided, read n bytes from the SSL connection, otherwise read until EOF. The return value is a string of the bytes read. - This is not ambiguous. Similarly, help(file.read) is not ambiguous. (The "at most" part in the first line of file.read is later explained to apply to non-blocking reads.) If you want to claim "well, it's not a file-like object" then (a) it shouldn't have file-like methods (socket-like send and recv are the obvious choices instead of write and read), (b) you need to fix your docs. But since god knows how many programs are out there expecting the semantics explained by the existing docs, I think just fixing the bug in the code is better than defining away the problem. (Obviously socket.makefile won't work on an object that doesn't implement a socket-like interface, so that's a non-option.) ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1291446> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1291446] SSLObject breaks read semantics
Jonathan Ellis <[EMAIL PROTECTED]> added the comment: Ah, great. I was wondering why you kept talking about SSLSocket instead of SSLObject. "New API in 2.6" is good enough for me. Thanks! ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1291446> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5882] __repr__ is ignored when formatting exceptions
New submission from Jonathan Ellis : The docs say that "If a class defines __repr__() but not __str__(), then __repr__() is also used when an “informal” string representation of instances of that class is required." but, repr is ignored: >>> class E(Exception): ... def __repr__(self): ... return 'fancy!' ... >>> raise E() Traceback (most recent call last): File "", line 1, in __main__.E only str is respected: >>> class E(Exception): ... def __str__(self): ... return 'fancy!' ... >>> raise E() Traceback (most recent call last): File "", line 1, in __main__.E: fancy! -- components: Interpreter Core messages: 86826 nosy: ellisj severity: normal status: open title: __repr__ is ignored when formatting exceptions type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue5882> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5882] __repr__ is ignored when formatting exceptions
Changes by Jonathan Ellis : -- versions: +Python 3.0 ___ Python tracker <http://bugs.python.org/issue5882> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com