Mailman 3 December 2015 - docs

[issue25495] binascii documentation incorrect
by Mouse Dec. 14, 2015

Dec. 14, 2015

New submission from Mouse: binascii b2a_base64() documentation says: The length of data should be at most 57 to adhere to the base64 standard. This is incorrect, because there is no base64 standard that restricts the length of input data, especially to such a small value. What RFC4648 (that superseded RFC3548 that your documentation still keeps referring to) actually says is that MIME enforces the limit ofthe OUTPUT LINE length at 76, but NOT of the entire output, and certainly not of the entire input. Please correct the documentation, making it conformant with what the ACTUAL base64 standard says. See https://en.wikipedia.org/wiki/Base64 and https://tools.ietf.org/html/rfc4648 Thanks! ---------- assignee: docs@python components: Documentation messages: 253572 nosy: docs@python, mouse07410 priority: normal severity: normal status: open title: binascii documentation incorrect versions: Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25495> _______________________________________

6 26

[issue1753718] base64 "legacy" functions violate RFC 3548
by R. David Murray Dec. 14, 2015

Dec. 14, 2015

R. David Murray added the comment: I started tweaking this patch, and wound up going through the whole doc and fixing the references to 'byte string' and 'string' throughout, as well as making all the entries consistent in how they reference the function arguments and output (previously some did not reference the output at all, nor was it clear that the output is always bytes). I believe I also clarified some confusing wordings along the way. Since there are so many changes I need some eyes checking my work before I commit. Note that the primary motivation for this change (the incorrect claim that both interfaces supported the RFC) is not made by the 2.7 docs, and since those docs are very different now, I don't plan to touch them. ---------- stage: -> patch review Added file: http://bugs.python.org/file41296/issue-01753718.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue1753718> _______________________________________

1 0

[issue16394] Reducing tee() memory footprint
by Serhiy Storchaka Dec. 12, 2015

Dec. 12, 2015

Changes by Serhiy Storchaka <storchaka(a)gmail.com>: ---------- nosy: -serhiy.storchaka _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16394> _______________________________________

1 0

[issue5501] Update multiprocessing docs re: freeze_support
by Berker Peksag Dec. 12, 2015

Dec. 12, 2015

Changes by Berker Peksag <berker.peksag(a)gmail.com>: ---------- nosy: +davin _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue5501> _______________________________________

1 0

[issue25730] invisible sidebar content with code snippets
by Berker Peksag Dec. 11, 2015

Dec. 11, 2015

Berker Peksag added the comment: This can be reproduced at https://docs.python.org/3/faq/windows.html You can find the CSS file at Doc/tools/pydoctheme/static/pydoctheme.css. You can override .highlight there, but the actual problem is that Sphinx creates the outer highlight-python3 div with "position: relative;". I think your CSS fix is good enough to commit. Thanks! ---------- nosy: +berker.peksag _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25730> _______________________________________

1 0

`contextlib.contextmanager` should include example with exception-handling
by Franklin? Lee Dec. 11, 2015

Dec. 11, 2015

(Link to docs: https://docs.python.org/3/library/contextlib.html#contextlib.contextmanager) I was surprised when I tried to use `contextmanager` with a block that threw an exception. After flailing around a bit on the REPL, I read the docs more carefully and saw that I had to wrap the `yield` with a `try-finally` block. I first learned about the `with` statement as a way to open files and guarantee (to some extent) that they'll be closed even if something went wrong. I associate `with` with C++'s RAII, where destructors are used to guarantee things happening at the end of scope. With that intuition, it was surprising to me that the default behavior did not handle exceptions, er, for me. I admit I could have been more careful, but maybe others have the same intuition, and would benefit from try-finally standing out more (i.e. an example) on that page.

1 0

[issue25666] Python unexpectedly ignores a signal after fork
by jon orebro Dec. 11, 2015

Dec. 11, 2015

New submission from jon orebro: Description: I found a slight problem with signal handling. It seems that if you have a signal handler setup for a signal, right after a fork the child ignores that signal for a short time. This is regardless of what the signal handler is setup to do. This can cause hangs if the parent immediately kills and then waits for the child. Since the timeframe is small, in practice this only happens sometimes (se example). There might be a reason for this behavour, but in that case I think it should me mentioned in the docs. What I expected: I expected the child to, at any point in time, either do the default action for the signal (terminate in this case), or to run the signal handler. What happens: It ignores the signal for a short while. Tested versions: Python 2.7.6 Python 3.4.0 ---------- assignee: docs@python components: Documentation, Interpreter Core files: example.py messages: 254890 nosy: docs@python, jon orebro priority: normal severity: normal status: open title: Python unexpectedly ignores a signal after fork type: behavior versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file41074/example.py _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25666> _______________________________________

3 3

Found a bug in the os.path.join function
by Ryan McCafferty Dec. 11, 2015

Dec. 11, 2015

Hello, I am running python v3.4.2 on a Raspberry Pi 2 running raspbian jesse. I found what I think is a bug with the os.path.join function. When passing multiple arguments to this function, which is usually the case, if any of the arguments contain a leading slash, all of the arguments that come before the one with the leading slash get truncated from the resulting path. >>> os.path.join('a', 'b', 'c') 'a/b/c' # this is expected >>> os.path.join('a', '/b', 'c') '/b/c' # expecting a/b/c >>> os.path.join('a', 'b', '/c') '/c' # expecting a/b/c >>> os.path.join('a', '/b', '/c') '/c' # expecting a/b/c I think this is a bug, because I believe the reasoning for these path join functions is so users do not have to worry about which path components contain leading or trailing slashes. Thank you, Ryan McCafferty

2 1

[issue22341] Python 3 crc32 documentation clarifications
by Martin Panter Dec. 11, 2015

Dec. 11, 2015

New submission from Martin Panter: This is regarding the Python 3 documentation for binascii.crc32(), <https://docs.python.org/dev/library/binascii.html#binascii.crc32>. It repeatedly recommends correcting the sign by doing crc32() & 0xFFFFFFFF, but it is not immediately clear why. Only after reading the Python 2 documentation does one realise that the value is always unsigned for Python 3, so you only really need the workaround if you want to support earlier Pythons. I also suggest documenting the initial CRC input value, which is zero. Suggested wording: binascii.crc32(data[, crc]) Compute CRC-32, the 32-bit checksum of “data”, starting with the given “crc”. The default initial value is zero. The algorithm is consistent with the ZIP file checksum. Since the algorithm is designed for use as a checksum algorithm, it is not suitable for use as a general hash algorithm. Use as follows: print(binascii.crc32(b"hello world")) # Or, in two pieces: crc = binascii.crc32(b"hello", 0) crc = binascii.crc32(b" world", crc) print('crc32 = {:#010x}'.format(crc)) I would simply drop the notice box with the workaround, because I gather that the Python 3 documentation generally omits Python 2 details. (There are no “new in version 2.4 tags” for instance.) Otherwise, clarify if “packed binary format” is a reference to the “struct” module, or something else. Similar fixes are probably appropriate for zlib.crc32() and zlib.alder32(). Also, what is the relationship between binascii.crc32() and zlib.crc32()? I vaguely remember reading that “zlib” is not always available, so I tend to use “binascii” instead. Is there any advantage in using the “zlib” version? The “hashlib” documentation points to “zlib” without mentioning “binascii” at all. ---------- assignee: docs@python components: Documentation messages: 226419 nosy: docs@python, vadmium priority: normal severity: normal status: open title: Python 3 crc32 documentation clarifications versions: Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue22341> _______________________________________

4 14

[issue25832] Document weird behavior of `finally` when it has `break` in it
by Ram Rachum Dec. 10, 2015

Dec. 10, 2015

New submission from Ram Rachum: Today I spent 30 minutes because of weird behavior of `finally` when it has a `break` statement inside of it. (The behavior is that the exception gets suppressed, which I found unexpected.) I think this behavior should be documented. Example: c:\Users\Administrator\Desktop>cat s.py for x in [1, 2, 3]: try: 1/0 finally: break print(x) c:\Users\Administrator\Desktop>c:\Python34\python.exe s.py 1 ---------- assignee: docs@python components: Documentation messages: 256173 nosy: cool-RR, docs@python priority: normal severity: normal status: open title: Document weird behavior of `finally` when it has `break` in it type: enhancement _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25832> _______________________________________

3 2