Mailman 3 October 2020 - docs

[issue12594] Docs for py3k still refer to "MacPython 2.5 folder"
by Christoph Schindler 04 Mar '21

04 Mar '21

New submission from Christoph Schindler <hop(a)30hopsmax.at>: In http://docs.python.org/py3k/using/mac.html#getting-and-installing-macpython and http://docs.python.org/py3k/using/mac.html#distributing-python-applications… . ---------- assignee: docs@python components: Documentation messages: 140744 nosy: docs@python, hop priority: normal severity: normal status: open title: Docs for py3k still refer to "MacPython 2.5 folder" versions: Python 3.1, Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12594> _______________________________________

7 11

[issue39199] Improve the AST documentation
by Pablo Galindo Salgado 03 Mar '21

03 Mar '21

New submission from Pablo Galindo Salgado <pablogsal(a)gmail.com>: The AST docs need some love as they can be a bit obscure to someone new to the module. Improvements to be considered in this issue: * Document all available nodes (as of 3.8 and not deprecated ones). This helps to know what classes to consider when implementing methods for the visitors. * Add some short practical examples for the visitors: one to query an AST and another to modify it. ---------- assignee: docs@python components: Documentation messages: 359235 nosy: docs@python, pablogsal priority: normal severity: normal status: open title: Improve the AST documentation versions: Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue39199> _______________________________________

2 9

[issue24650] Error in yield expression documentation
by swanson 27 Feb '21

27 Feb '21

New submission from swanson: https://docs.python.org/3/reference/expressions.html in 6.2.9. Yield expressions end of 1st paragraph: "Using a yield expression in a function’s body causes that function to be a generator." NO! As the very next sentence explains, a generator is what's returned by such a function, not the function itself. Basically, it should be sufficient to add the word "function" to the end of that sentence: "... generator function." However, this error does NOT exist in 3.0 to 3.2 - just in 3.3 to 3.6, so I suggest just using the same wording as 3.0 to 3.2: "Using a yield expression in a function definition is sufficient to cause that definition to create a generator function instead of a normal function." ---------- assignee: docs@python components: Documentation messages: 246841 nosy: docs@python, swanson priority: normal severity: normal status: open title: Error in yield expression documentation versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue24650> _______________________________________

4 4

[issue29045] Outdated C api doc about Windows error
by Xiang Zhang 26 Feb '21

26 Feb '21

New submission from Xiang Zhang: https://docs.python.org/3.7/c-api/exceptions.html#c.PyErr_SetFromWindowsErr… it stills refers to PyErr_SetFromWindowsErrWithFilenameObject but this function doesn't exist since Py3.4. I didn't find when and why it's deleted. And https://docs.python.org/3.4/c-api/exceptions.html#c.PyErr_SetFromWindowsErr raises OSError instead of WindowsError. ---------- assignee: docs@python components: Documentation messages: 283814 nosy: docs@python, xiang.zhang priority: normal severity: normal status: open title: Outdated C api doc about Windows error versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue29045> _______________________________________

2 3

[issue24045] Behavior of large returncodes (sys.exit(nn))
by Ethan Furman 26 Feb '21

26 Feb '21

New submission from Ethan Furman: Not sure if this is a bug, or just One of Those Things: sys.exit(large_value) can wrap around if the value is too large, but this is O/S dependent. linux (ubuntu 14.04) $ python Python 2.7.8 (default, Oct 20 2014, 15:05:29) [GCC 4.9.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. --> import sys --> sys.exit(256) $ echo $? 0 $ python Python 2.7.8 (default, Oct 20 2014, 15:05:29) [GCC 4.9.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. --> import sys --> sys.exit(257) $ echo $? 1 M$ (Windows 7) > python Python 2.7... --> import sys --> sys.exit(65535) > echo %errorlevel% 65535 > python Python 2.7... --> import sys --> sys.exit(100000) > echo %errorlevel% 100000 Perhaps a minor doc update that talks about return codes and why they might not be exactly what was given to Python? ---------- assignee: docs@python messages: 241903 nosy: docs@python, ethan.furman priority: normal severity: normal status: open title: Behavior of large returncodes (sys.exit(nn)) versions: Python 2.7, Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue24045> _______________________________________

4 5

[issue13368] Possible problem in documentation of module subprocess, method send_signal
by Eli Bendersky 24 Feb '21

24 Feb '21

New submission from Eli Bendersky <eliben(a)gmail.com>: docs@ list report by Daniel Dieterle: in the documentation (http://docs.python.org/library/subprocess.html#subprocess.Popen.send_signal) is a bug. CTRL_C_EVENT can not be sent to processes started with a creationflags parameter which includes CREATE_NEW_PROCESS_GROUP. Why can be read in the msdn documentation http://msdn.microsoft.com/en-us/library/windows/desktop/ms683155%28v=vs.85%… . A workaround using CTRL_C_EVENT nevertheless is described here: http://stackoverflow.com/questions/7085604/sending-c-to-python-subprocess-o… -- I do not know why the subprocess.CREATE_NEW_PROCESS_GROUP parameter was introduced. But it is useless for terminating a process with os.kill() in combination with signal.SIGTERM, which corresponds to a CTRL-C-EVENT. A CTRL-C-EVENT is only forwarded to the process if the process group is zero. Therefore the Note in the documentation on Popen.send_signal() is wrong. ---------- assignee: docs@python components: Documentation messages: 147272 nosy: docs@python, eli.bendersky priority: normal severity: normal status: open title: Possible problem in documentation of module subprocess, method send_signal versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13368> _______________________________________

4 6

[issue16954] Add docstrings for ElementTree module
by Serhiy Storchaka 21 Feb '21

21 Feb '21

New submission from Serhiy Storchaka: Perhaps almost all Doxygen comments in ElementTree module should be converted to docstrings. ---------- assignee: docs@python components: Documentation, XML messages: 179881 nosy: docs@python, eli.bendersky, serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: Add docstrings for ElementTree module type: enhancement versions: Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue16954> _______________________________________

8 23

[issue27646] yield from expression can be any iterable
by Terry J. Reedy 20 Feb '21

20 Feb '21

New submission from Terry J. Reedy: https://docs.python.org/3/reference/expressions.html#yield-expressions says "When yield from <expr> is used, it treats the supplied expression as a subiterator. All values produced by that subiterator ...". To me "treats..expression as a subiterator" means that the expression must *be* an iterator, such as returned by iter or calling a generator function. Hence I was surprised upon reading "yield from <non-iterator iterable>" in stdlib code. I confirmed that this usage is correct by trying >>> def g(): yield from (1,2) >>> i = g() >>> next(i), next(i) (1, 2) and then reading the PEP380 Formal Semantics, which begins with "_i = iter(EXPR)". Hence I suggest the following replacement for the quote above: "When yield from <expr> is used, the expression must be an iterable. A subiterator is obtained with iter(<expr>). All values produced by that subiterator ...". Note that 'subiterator' is spelled in the following sentences 'underlying iterable' (which I am not sure I like) and 'sub-iterator' (and 'sub-generator'). I think we should be consistent for at least the two short 'yield from' paragraphs. ---------- assignee: docs@python components: Documentation messages: 271577 nosy: docs@python, terry.reedy priority: normal severity: normal stage: patch review status: open title: yield from expression can be any iterable type: behavior versions: Python 3.5, Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue27646> _______________________________________

3 8

[issue13433] String format documentation contains error regarding %g
by Christian Iversen 18 Feb '21

18 Feb '21

New submission from Christian Iversen <ci(a)sikkerhed.org>: The documentation for string format options state that both %f, %g and %e default to 6 digits after the decimal point. In fact, %g always seems to use 5 digits by default: >>> "%g" % 2.1234567 '2.12346' >>> "%f" % 2.1234567 '2.123457' >>> "%e" % 2.1234567 '2.123457e+00' But something much more insidious is wrong, because even when explicitly told how many digits to have, %g is one off: >>> "%.6g" % 2.1234567 '2.12346' >>> "%.6f" % 2.1234567 '2.123457' >>> "%.6e" % 2.1234567 '2.123457e+00' This can't be right? ---------- assignee: docs@python components: Documentation messages: 147940 nosy: Christian.Iversen, docs@python priority: normal severity: normal status: open title: String format documentation contains error regarding %g type: behavior versions: Python 2.6, Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13433> _______________________________________

6 11

[issue29086] Document C API that is not part of the limited API
by Serhiy Storchaka 18 Feb '21

18 Feb '21

New submission from Serhiy Storchaka: >From the documentation: https://docs.python.org/3/c-api/stable.html In the C API documentation, API elements that are not part of the limited API are marked as "Not part of the limited API." But they don't. Following sample patch adds the notes to Unicode Objects and Codecs C API. I'm going to add them to all C API. What are your though about formatting the note? Should it be before the description, after the description, but before the "deprecated" directive (as in the patch), or after the first paragraph of the description? Should it be on the separate line or be appended at the end of the previous paragraph, or starts the first paragraph (if before the description)? May be introduce a special directive for it? ---------- assignee: docs@python components: Documentation files: unicode-not-part-of-the-limited-api.patch keywords: patch messages: 284125 nosy: docs@python, georg.brandl, serhiy.storchaka priority: normal severity: normal status: open title: Document C API that is not part of the limited API type: enhancement versions: Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46057/unicode-not-part-of-the-limited-api.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue29086> _______________________________________

5 6