Mailman 3 November 2015 - docs

[issue20782] base64 module docs do not use the terms 'bytes' and 'string' consistently.
by R. David Murray 24 Dec '15

24 Dec '15

New submission from R. David Murray: The base64 documentation (http://docs.python.org/3/library/base64.html) does not use the new python3 byte/string terminology consistently (sometimes not even within the same paragraph). ---------- assignee: docs@python components: Documentation messages: 212258 nosy: docs@python, r.david.murray priority: normal severity: normal stage: needs patch status: open title: base64 module docs do not use the terms 'bytes' and 'string' consistently. type: behavior versions: Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue20782> _______________________________________

4 5

[issue25580] async and await missing from token list
by SilentGhost 18 Dec '15

18 Dec '15

New submission from SilentGhost: With introduction of async and await tokens in 3.5 the token documentation needs updating. ---------- assignee: docs@python components: Documentation files: token.diff keywords: patch messages: 254281 nosy: SilentGhost, docs@python priority: normal severity: normal stage: patch review status: open title: async and await missing from token list versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file40974/token.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25580> _______________________________________

5 14

[issue20837] Ambiguity words in base64 documentation
by INADA Naoki 14 Dec '15

14 Dec '15

New submission from INADA Naoki: http://docs.python.org/3/library/base64.html > The modern interface supports encoding and decoding ASCII byte string objects using all three alphabets. What "all three alphabets" means? I think it is about *altchars*. But the sentence is too ambiguous to translate it in Japanese. ---------- assignee: docs@python components: Documentation messages: 212604 nosy: docs@python, naoki priority: normal severity: normal status: open title: Ambiguity words in base64 documentation versions: Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue20837> _______________________________________

6 8

[issue25495] binascii documentation incorrect
by Mouse 14 Dec '15

14 Dec '15

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

[issue25666] Python unexpectedly ignores a signal after fork
by jon orebro 11 Dec '15

11 Dec '15

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

[issue22341] Python 3 crc32 documentation clarifications
by Martin Panter 11 Dec '15

11 Dec '15

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

sum( ) in generator bugged
by Anselm Kiefner 09 Dec '15

09 Dec '15

Hi, I just found this bug: Python 3.4.3+ (default, Oct 14 2015, 16:03:50) [GCC 5.2.1 20151010] on linux >>> L = [1,2,3] >>> L_g = (x for x in L) >>> a = [x*sum(L) for x in L] >>> b = (x*sum(L_g) for x in L_g) >>> print(a, list(b)) [6, 12, 18] [5] whether b is a generator or not doesn't make a difference, it seems to be a problem with sum() operating on L_g while L_g is consumed. I stumbled over the problem first in ipython notebook running python kernel 3.5.0, but couldn't find anything about it in the bugtracker. Thanks, Anselm

3 5

[issue21240] Add an abstactmethod directive to the Python ReST domain
by Eric Snow 08 Dec '15

08 Dec '15

New submission from Eric Snow: I'd like to be able to mark abstract methods in the docs more explicitly and have their presentation in the docs be more obvious. So I'd like to propose "abstractmethod" as a new directive to join the existing ones (classmethod, staticmethod, etc.). (This is motivated by msg216314.) ---------- assignee: docs@python components: Documentation messages: 216323 nosy: docs@python, eric.snow priority: normal severity: normal status: open title: Add an abstactmethod directive to the Python ReST domain type: enhancement versions: Python 3.4, Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue21240> _______________________________________

6 7

[issue23936] Wrong references to deprecated find_module instead of find_spec
by Raúl Cumplido 05 Dec '15

05 Dec '15

New submission from Raúl Cumplido: While taking a look on the import mechanisms I've seen in the documentation that find_module has been deprecated for find_spec, but on different parts of the documentation there are still references to find_module, as in the definition of sys.meta_path (https://docs.python.org/3/library/sys.html#sys.meta_path). Shouldn't it be (example on this case) a list of finder objects that have their find_spec() methods called, instead of find_module method? I've been taking a look on _bootstrap.py and I can see we call find_spec: for finder in sys.meta_path: with _ImportLockContext(): try: find_spec = finder.find_spec If you agree with me that this is wrong I'll submit a patch to fix it. ---------- assignee: docs@python components: Documentation messages: 240671 nosy: brett.cannon, docs@python, eric.snow, raulcd priority: normal severity: normal status: open title: Wrong references to deprecated find_module instead of find_spec versions: Python 3.4, Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23936> _______________________________________

5 14

[issue25500] _find_and_load_unlocked doesn't always use __import__
by Sergei Lebedev 04 Dec '15

04 Dec '15

New submission from Sergei Lebedev: According to the current import system documentation > When calling ``__import__()`` as part of an import statement, the import system first checks the module global namespace for a function by that name. If it is not found, then the standard builtin ``__import__()`` is called. However, one can easily verify this isn't (always) the case:: import sys assert "glob" not in sys.modules __import__ = print import glob # Doesn't print anything. I've traced the import statement from ``ceval.c`` to the frozen ``importlib._bootstrap`` and it seems the cause of the problem is in ``_find_and_load_unlocked``, which simply ignores the ``_import`` argument in the case above:: def _find_and_load_unlocked(name, import_): path = None # ... parent processing ... spec = _find_spec(name, path) if spec is None: raise ImportError(_ERR_MSG.format(name), name=name) else: # XXX import_ is not used. module = _SpecMethods(spec)._load_unlocked() # ... more parent processing ... return module I'm not sure if this is a bug in the documentation or implementation, so any feedback is appreciated. ---------- assignee: docs@python components: Documentation, Library (Lib) messages: 253635 nosy: docs@python, superbobry priority: normal severity: normal status: open title: _find_and_load_unlocked doesn't always use __import__ versions: Python 3.4, Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25500> _______________________________________

4 6