Mailman 3 February 2015 - docs

[issue6634] sys.exit() called from threads other than the main one: undocumented behaviour
by Jan-Philip Gehrcke 02 Feb '15

02 Feb '15

Jan-Philip Gehrcke added the comment: For Python 3.5, I have attached a patch that - adds relevant test cases to test_threading.py which probe the interpreter's stderr output for compliance with what the docs state. - makes sys.exit(msg) write msg to stderr, even if called from a non-primary thread, so that the tests succeed. If we take this path, the documentation for 3.5 does not need to be adjusted. The discussion in this thread diversified itself a bit: > Why don't threads have their own ThreadExit exception, > rather than overloading the use, and therefore, the > meaning, of the SystemExit exception? sys.exit and the > SystemExit exception should *only* be used to exit the > entire system, not just a thread! While I absolutely agree that this would be conceptually cleaner, implementing this would be a larger refactoring task. Deciding whether this should be done or not slows this issue down, and I think this discussion should probably be taken elsewhere. ---------- versions: +Python 3.5 -Python 3.1, Python 3.2 Added file: http://bugs.python.org/file37986/issue6634_py35.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue6634> _______________________________________

1 0

[issue6634] sys.exit() called from threads other than the main one: undocumented behaviour
by Jan-Philip Gehrcke 02 Feb '15

02 Feb '15

Changes by Jan-Philip Gehrcke <jgehrcke(a)gmail.com>: Removed file: http://bugs.python.org/file19006/thread_sys_exit_test.py _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue6634> _______________________________________

1 0

[issue6634] sys.exit() called from threads other than the main one: undocumented behaviour
by Jan-Philip Gehrcke 02 Feb '15

02 Feb '15

Jan-Philip Gehrcke added the comment: For Python 2.7, we will not change behavior, even if unexpected. Instead, the sys.exit-docs should be adjusted and - warn about the fact that nothing is written to stderr if sys.exit(msg) gets called from a non-primary thread, and - note that SystemExit raised in a non-primary thread lets the thread exit silently. I have attached a corresponding patch, please review my wording! ---------- keywords: +patch Added file: http://bugs.python.org/file37983/issue6634_py27.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue6634> _______________________________________

1 0

[issue23352] Document "suboffsets if needed" in 2.7
by Stefan Krah 02 Feb '15

02 Feb '15

Changes by Stefan Krah <stefan(a)bytereef.org>: ---------- resolution: -> fixed stage: -> resolved status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23352> _______________________________________

1 0

[issue13322] buffered read() and write() does not raise BlockingIOError
by Martin Panter 02 Feb '15

02 Feb '15

Martin Panter added the comment: Looking at test_io.BufferedReaderTest.test_read_non_blocking(), at Lib/test/test_io.py:1037, there are explicit tests for ‘peek(1) == b"" ’ and ‘read() is None’. The peek() test was added in revision 3049ac17e256, in 2009 (large merge of “io” implementation in C; can’t find more detailed history). The read() test was added in revision 21233c2e5d09 in 2007, with a remark about a “tentative decision to drop nonblocking I/O support from the buffering layers”. My suggestion is to make the read/into/1/all/peek() methods all return None if no non-blocking data is available, and return a short non-empty result if some data was available but not enough to satisfy the equivalent blocking call. However, this would invove changing the behaviour of BufferedReader.read1() and peek(); would that be allowed? The readline() based methods could probably work similarly, but that would be another issue and a bigger change, because the equivalent RawIOBase methods do not return None. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13322> _______________________________________

1 0

[issue23352] Document "suboffsets if needed" in 2.7
by Roundup Robot 01 Feb '15

01 Feb '15

Roundup Robot added the comment: New changeset c4c1d68b6301 by Stefan Krah in branch '2.7': Issue #23352: Document that Py_buffer.suboffsets must be NULL if no suboffsets https://hg.python.org/cpython/rev/c4c1d68b6301 New changeset de5c8ee002bf by Stefan Krah in branch '3.4': Issue #23352: Document that Py_buffer.suboffsets must be NULL if no suboffsets https://hg.python.org/cpython/rev/de5c8ee002bf New changeset 5d097a74766f by Stefan Krah in branch 'default': Issue #23352: Merge from 3.4. https://hg.python.org/cpython/rev/5d097a74766f ---------- nosy: +python-dev _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23352> _______________________________________

1 0

[issue23352] Document "suboffsets if needed" in 2.7
by Stefan Krah 01 Feb '15

01 Feb '15

Stefan Krah added the comment: But only Cython does not set suboffsets to NULL and you already have a small patch to fix that. The Python 3 docs say "suboffsets only if needed" and the PEP says the same, so the situation is not completely undocumented. I think your doc patch goes too far. Buffers propagate in unpredictable ways, and since the original consumer request is *not stored* in the buffer, setting unneeded fields to NULL provides a way to figure out the original request. It is actually *an optimization* to set suboffsets to NULL: Compliant code that uses arbitrary buffers always has to check for: if (suboffsets != NULL && suboffsets[i] >= 0) ... If suboffsets are consistently NULL, at least hopefully you get branch prediction to kick in. As Sebastian pointed out, it's relatively easy even for slicing/indexing functions to check for all-negative suboffsets and handle that case. All this is probably academic, since no one appears to be using suboffsets at all. :) Let's keep the status-quo and make this a doc issue for 2.7. ---------- assignee: -> docs@python components: +Documentation -Interpreter Core nosy: +docs@python priority: normal -> low stage: patch review -> title: PyBuffer_IsContiguous() sometimes returns wrong result if suboffsets != NULL -> Document "suboffsets if needed" in 2.7 type: behavior -> enhancement _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23352> _______________________________________

1 0

Improve socketserver doc (issue 15608)
by berker.peksag＠gmail.com 01 Feb '15

01 Feb '15

http://bugs.python.org/review/15608/diff/13802/Doc/library/socketserver.rst File Doc/library/socketserver.rst (right): http://bugs.python.org/review/15608/diff/13802/Doc/library/socketserver.rst… Doc/library/socketserver.rst:16: .. class:: TCPServer Could you please document its constructor, too? http://bugs.python.org/review/15608/diff/13802/Doc/library/socketserver.rst… Doc/library/socketserver.rst:36: For more details on network programming, consult a book such as I'd remove this paragraph. http://bugs.python.org/review/15608/diff/13802/Doc/library/socketserver.rst… Doc/library/socketserver.rst:104: class ThreadingUDPServer(ThreadingMixIn, UDPServer): pass class ThreadingUDPServer(ThreadingMixIn, UDPServer): pass http://bugs.python.org/review/15608/diff/13802/Doc/library/socketserver.rst… Doc/library/socketserver.rst:112: ForkingUDPServer .. class:: ForkingTCPServer ForkingUDPServer ... http://bugs.python.org/review/15608/diff/13802/Doc/library/socketserver.rst… Doc/library/socketserver.rst:353: .. method:: BaseRequestHandler.setup() Please indent this and rest of the method. That way you won't need to add "RequestHandler." to method names: .. class:: BaseRequestHandler [...] .. method:: setup() [...] http://bugs.python.org/review/15608/

1 0