Mailman 3 August 2020 - docs

[issue25912] Use __spec__.__name__ instead of __name__ in the docs where appropriate
by Antony Lee 11 Sep '20

11 Sep '20

New submission from Antony Lee: There are a couple of places in the docs where it would be appropriate to replace __name__ by __spec__.__name__ in order to support the case where the module is executed as the __main__ module: - logging.getLogger should certainly use __spec__.__name__ so that the logger hierarchy be respected (otherwise, when running "python -mpkg.subpkg", the logger of pkg.subpkg is named "__main__" and thus not a child of the "pkg" logger). - examples for argparse.ArgumentParser (e.g. in the docs for venv) should use __spec__.__name__ instead of __name__ for the "prog=" argument. (not guaranteed to be exhaustive) ---------- assignee: docs@python components: Documentation messages: 256743 nosy: Antony.Lee, docs@python priority: normal severity: normal status: open title: Use __spec__.__name__ instead of __name__ in the docs where appropriate versions: Python 3.5, Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25912> _______________________________________

2 3

[issue38585] defusedexpat not supported past python 3.3/3.4
by Avi Kelman 06 Sep '20

06 Sep '20

New submission from Avi Kelman <avikelman(a)d3b.center>: https://docs.python.org/3/library/xml.html continues to recommend defusedexpat, but that package won't install for any Python versions after 3.4 because the package isn't being maintained. https://bitbucket.org/tiran/defusedexpat/src/default/ linked from https://pypi.org/project/defusedexpat/ stops at 3.3. https://github.com/tiran/defusedexpat stops at 3.4. If the package doesn't actually work for newer Pythons, the recommendation should be removed from official documentation. ---------- assignee: docs@python components: Documentation messages: 355337 nosy: Avi Kelman, docs@python priority: normal severity: normal status: open title: defusedexpat not supported past python 3.3/3.4 type: behavior versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue38585> _______________________________________

5 8

[issue40486] pathlib's iterdir doesn't expecify what happens if directory content change
by Facundo Batista 05 Sep '20

05 Sep '20

New submission from Facundo Batista <facundo(a)taniquetil.com.ar>: Documentation for Path.iterdir ( https://docs.python.org/3/library/pathlib.html#pathlib.Path.iterdir ) doesn't specify what happens when the directory change. This is important, as the function does NOT return a list (which would imply that a "snapshot" of the directory will be returned). Also, it's not only relevant what would happen if somebody else changes the directory after the iteration is started (will that change be reflected?) but also if it's ALLOWED for the same code that iterates the dir content to change it (or problems would arise, like when changing a dictionary while being iterated). ---------- assignee: docs@python components: Documentation messages: 367981 nosy: docs@python, facundobatista priority: normal severity: normal status: open title: pathlib's iterdir doesn't expecify what happens if directory content change versions: Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue40486> _______________________________________

4 10

[issue35228] Index search in CHM help crashes viewer
by Christian Ullrich 04 Sep '20

04 Sep '20

New submission from Christian Ullrich <chris(a)chrullrich.net>: Typing into the index keyword field frequently crashes the CHM viewer with the first or second character. The Python CHMs are the only ones that I see this crash with; it started around 3.6 or so. >From event log: Faulting application name: hh.exe, version: 10.0.17134.1, time stamp: 0xa0eff942 Faulting module name: hhctrl.ocx, version: 10.0.17134.48, time stamp: 0x412ce02a Exception code: 0xc0000005 Fault offset: 0x00000000000387b2 Faulting process ID: 0x3558 Faulting application start time: 0x01d47b3f8db53eef Faulting application path: C:\Windows\hh.exe Faulting module path: C:\Windows\System32\hhctrl.ocx Report ID: 53f84d38-adb4-4c0b-bd45-9bce02406e6f Faulting package full name: Faulting package-relative application ID: This particular crash involved the file from 3.7.1: sha1(doc\python371.chm) = 1c0e2d861cadc759436bfac0a767c5bb633423f9 ---------- assignee: docs@python components: Documentation, Windows messages: 329824 nosy: chrullrich, docs@python, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Index search in CHM help crashes viewer type: behavior versions: Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue35228> _______________________________________

7 14

[issue30826] More details in reference 'Looping through a list in Python and modifying it'
by Anmol Gupta 03 Sep '20

03 Sep '20

New submission from Anmol Gupta: Documentation section: https://docs.python.org/3/reference/compound_stmts.html#for The documentation does not explain at all why is there an infinite loop when not using a copy of the list. It leaves the reader in a confused state. Even there are questions concerning the same on stackoverlflow: https://stackoverflow.com/questions/44633798/loop-through-a-list-in-python-… ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue30826> _______________________________________

6 13

[issue41191] PyType_FromModuleAndSpec is not mentioned in 3.9 What's new
by Matthieu Dartiailh 03 Sep '20

03 Sep '20

New submission from Matthieu Dartiailh <m.dartiailh(a)gmail.com>: Looking at the What's new for Python 3.9 I noticed that there was no mention of PEP 573. The added functions are properly documented and should probably be mentioned in the What's new. ---------- assignee: docs@python components: Documentation messages: 372790 nosy: docs@python, mdartiailh priority: normal severity: normal status: open title: PyType_FromModuleAndSpec is not mentioned in 3.9 What's new versions: Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue41191> _______________________________________

4 4

[issue40204] Docs build error with Sphinx 3.0 due to invalid C declaration
by Karthikeyan Singaravelan 02 Sep '20

02 Sep '20

New submission from Karthikeyan Singaravelan <tir.karthi(a)gmail.com>: The following error is caused in Docs build for a 3.8 backport since sphinx is ran with warnings. Sphinx released 3.0 on April 6. The last successful build on master uses Sphinx 2.2.0 [0]. My guess is sphinx new version possibly breaking the build on Python 3.8 where it's not pinned to use 2.2.0 pulling the latest version. The changelog for Sphinx has below note : https://www.sphinx-doc.org/en/master/changes.html#release-3-0-0-released-ap… The C domain has been rewritten, with additional directives and roles. The existing ones are now more strict, resulting in new warnings. Python 3.8 and Python 3.7 doesn't have Sphinx pinned to 2.2.0 while master does. Python 3.8 Docs makefile : https://github.com/python/cpython/blob/f7b0259d0d243a71d79a3fda9ec7aad43065… Failed build : https://github.com/python/cpython/pull/19388/checks?check_run_id=563053793#… Error : Warning, treated as error: /home/runner/work/cpython/cpython/Doc/c-api/buffer.rst:92:Error in declarator or parameters Invalid C declaration: Expected identifier in nested name. [error at 5] void \*buf -----^ Makefile:49: recipe for target 'build' failed make[1]: *** [build] Error 2 [0] https://github.com/python/cpython/runs/564123625#step:6:24 ---------- assignee: docs@python components: Documentation messages: 365858 nosy: docs@python, eric.araujo, ezio.melotti, mdk, rhettinger, vstinner, willingc, xtreak priority: normal severity: normal status: open title: Docs build error with Sphinx 3.0 due to invalid C declaration type: behavior versions: Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue40204> _______________________________________

11 61

[issue41400] Remove references to nonexisting __ne__ methods
by Serhiy Storchaka 31 Aug '20

31 Aug '20

New submission from Serhiy Storchaka <storchaka+cpython(a)gmail.com>: There is the documentation for method __ne__ implementations in classes Set, Mapping, Header, Charset, Binary, but all these implementations are removed now and the default implementation of object.__ne__ is used instead. ---------- assignee: docs@python components: Documentation messages: 374309 nosy: barry, docs@python, maxking, r.david.murray, serhiy.storchaka priority: normal severity: normal status: open title: Remove references to nonexisting __ne__ methods type: enhancement versions: Python 3.10, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue41400> _______________________________________

3 6

[issue41676] asyncio.Event.wait broken link from asyncio.Event
by Thomas Grainger 31 Aug '20

31 Aug '20

New submission from Thomas Grainger <tagrain(a)gmail.com>: https://docs.python.org/dev/library/asyncio-sync.html#asyncio.Event links to https://docs.python.org/dev/library/asyncio-task.html#asyncio.wait instead of https://docs.python.org/dev/library/asyncio-sync.html#asyncio.Event.wait ---------- assignee: docs@python components: Documentation messages: 376153 nosy: docs@python, graingert priority: normal severity: normal status: open title: asyncio.Event.wait broken link from asyncio.Event versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue41676> _______________________________________

3 4

[issue39671] Mention in docs that asyncio.FIRST_COMPLETED does not guarantee the completion of no more than one task
by Tom Pohl 31 Aug '20

31 Aug '20

New submission from Tom Pohl <thomas.pohl(a)gmail.com>: Currently, the documentation of asyncio.wait gives the impression that using FIRST_COMPLETED guarantees the completion of no more than one task. In reality, the number of completed task after asyncio.wait can be larger than one. While this behavior (exactly one complete task if no error or cancellation occurred) would be ultimately desirable, a sentence describing the current behavior would be helpful for new users of asyncio. ---------- assignee: docs@python components: Documentation messages: 362181 nosy: docs@python, tom.pohl priority: normal severity: normal status: open title: Mention in docs that asyncio.FIRST_COMPLETED does not guarantee the completion of no more than one task type: enhancement versions: Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue39671> _______________________________________

3 2