Mailman 3 January 2021 - docs

[issue9694] argparse required arguments displayed under "optional arguments"
by Miro Hrončok 08 Jan '21

08 Jan '21

Miro Hrončok <miro(a)hroncok.cz> added the comment: https://bugs.python.org/issue42870 ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue9694> _______________________________________

1 0

[issue42820] Sphinx conf.py needs_version entry is outdated
by Tim Hoffmann 08 Jan '21

08 Jan '21

New submission from Tim Hoffmann <tim.hoffmann(a)posteo.de>: The sphinx conf.py entry `needs_version=1.8` (https://github.com/python/cpython/blob/1470edd6131c29b8a09ce012cdfee3afa269…) is not in sync with the doc build requirements (https://github.com/python/cpython/blob/1470edd6131c29b8a09ce012cdfee3afa269…) Possible solutions: a) Drop the `needs_version` config value. It's optional. b) Make sure to update both places. c) Or at minimum add a comment that `needs_version` is only a safeguard against very old sphinx versions but is not necessarily sufficient to build. ---------- assignee: docs@python components: Documentation messages: 384305 nosy: docs@python, timhoffm priority: normal severity: normal status: open title: Sphinx conf.py needs_version entry is outdated _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue42820> _______________________________________

2 2

[issue9694] argparse required arguments displayed under "optional arguments"
by paul j3 08 Jan '21

08 Jan '21

paul j3 <ajipanca(a)gmail.com> added the comment: Since this issue is closed it might be a good idea to open a new one with this problem. And if possible identify the failed tests. We forgot to allow for the fact that working code/tests might be checking for specific help messages, checks the will fail when this group label is changed. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue9694> _______________________________________

1 0

[issue41742] Request for docs.python.org/3/library/configparser.html#exceptions improvement
by leveque 08 Jan '21

08 Jan '21

New submission from leveque <jean-francois.leveque(a)sorbonne-universite.fr>: Hi, docs.python.org/3/library/configparser.html#exceptions does not mention KeyError which is mentioned under https://docs.python.org/3/library/configparser.html#mapping-protocol-access and https://docs.python.org/3/library/configparser.html#customizing-parser-beha…. Could it be added ? Cheers, ---------- assignee: docs@python components: Documentation messages: 376551 nosy: docs@python, leveque priority: normal severity: normal status: open title: Request for docs.python.org/3/library/configparser.html#exceptions improvement type: enhancement versions: Python 3.10, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue41742> _______________________________________

3 2

[issue9694] argparse required arguments displayed under "optional arguments"
by Miro Hrončok 08 Jan '21

08 Jan '21

Miro Hrončok <miro(a)hroncok.cz> added the comment: Coudl this please be mentioned on https://docs.python.org/3.10/whatsnew/3.10.html ? At least two packages fail tests because of the change (ipython and sphinxcontrib-autoprogram). ---------- nosy: +hroncok _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue9694> _______________________________________

1 0

[issue14655] traceback module docs should show how to print/fomat an exception object
by Irit Katriel 08 Jan '21

08 Jan '21

Irit Katriel <iritkatriel(a)yahoo.com> added the comment: In issue 26389 the api was changed so that now format_exception(exc) works. ---------- resolution: -> duplicate stage: needs patch -> resolved status: open -> closed superseder: -> Expand traceback module API to accept just an exception as an argument _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue14655> _______________________________________

1 0

[issue42836] docs: struct: clarify struct caching behaviour
by Sandeep Subramanian 08 Jan '21

08 Jan '21

New submission from Sandeep Subramanian <sandeep(a)mercari.com>: As per docs in :https://docs.python.org/3.7/library/struct.html#struct.Struct > The compiled versions of the most recent format strings passed to Struct and the module-level functions are cached, so programs that use only a few format strings needn’t worry about reusing a single Struct instance. This statement seems to imply that the format string passed as `struct.Struct(format)` is also cached. This doesn't appear to be the case. Only format strings passed to the module level functions seems to be cached. `cache_struct_converter` at https://github.com/python/cpython/blob/v3.7.7/Modules/_struct.c#L2052 appears to be used only in the top module level functions `pack` and `pack_into` and is *not* used in `Struct.__init__`. Would it be better to change the doc to: > The compiled versions of the most recent format strings passed to the module-level functions are cached, so programs that use only a few format strings needn’t worry about reusing a single Struct instance. This issue was introduced by https://github.com/python/cpython/commit/3666b3c1f695a145adab1bf644c22e564e… and is present in every version since. Refs: https://github.com/python/cpython/pull/7700 https://bugs.python.org/issue33032 ---------- assignee: docs@python components: Documentation messages: 384476 nosy: docs@python, sandeep2 priority: normal severity: normal status: open title: docs: struct: clarify struct caching behaviour type: enhancement versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue42836> _______________________________________

2 1

[issue42859] smtplib: recipe for certifying message delivery
by Dmitry Goldenberg 07 Jan '21

07 Jan '21

New submission from Dmitry Goldenberg <dgoldenberg123(a)gmail.com>: Is there a reliable way to certify (ensure, track) the delivery of an email message when using smtplib? For example: Disposition-Notification-To message header which enables the e-mail reader of the recipient to send confirmation e-mail when the recipient opens the message for the first time. That e-mail reader program must support this functionality. Return-Receipt-To message header which enables the e-mail server of the recipient to send confirmation e-mail when the original e-mail gets received by that server. However, most newer e-mail servers do not support Return-Receipt-To header. Are these message headers at all reliable? The request is to enhance the documentation to provide an example of how to track a message delivery. Conversely, if it's plain not possible, the request is to state that explicitly in the docs. ---------- assignee: docs@python components: Documentation messages: 384600 nosy: dgoldenberg123, docs@python priority: normal severity: normal status: open title: smtplib: recipe for certifying message delivery type: enhancement versions: Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue42859> _______________________________________

2 2

[issue42783] asyncio.sleep(0) idiom is not documented
by Simon Willison 07 Jan '21

07 Jan '21

New submission from Simon Willison <swillison(a)gmail.com>: asyncio.sleep(0) is the recommended idiom for co-operatively yielding control of the event loop to another task: https://github.com/python/asyncio/issues/284 and https://til.simonwillison.net/python/yielding-in-asyncio This isn't currently explained in the documentation. ---------- assignee: docs@python components: Documentation, asyncio messages: 384025 nosy: asvetlov, docs@python, simonw, yselivanov priority: normal severity: normal status: open title: asyncio.sleep(0) idiom is not documented type: enhancement _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue42783> _______________________________________

3 4

[issue42179] Clarify chaining exceptions in tutorial/errors.rst
by Vladimir Ryabtsev 06 Jan '21

06 Jan '21

New submission from Vladimir Ryabtsev <greatvovan(a)gmail.com>: A new section has been added to the page as a result of https://bugs.python.org/issue37826. The change: https://github.com/python/cpython/commit/dcfe111eb5602333135b8776996332a8dc… The wording it uses (in the beginning of section 8.5), defines chaining as setting __cause__ attribute in an exception, and later states that "Exception chaining happens automatically when an exception is raised inside an exception handler or finally section". This may lead the reader to a wrong idea that re-raising an exception without "from" in "except" and "finally" automatically sets __cause__. In reality it sets only __context__ attribute, which is similar concept to __cause__, but work a bit differently, as explained in library/exceptions.rst. I suggest to mention that difference and provide a link to the main article. ---------- assignee: docs@python components: Documentation messages: 379823 nosy: Vladimir Ryabtsev, docs@python priority: normal severity: normal status: open title: Clarify chaining exceptions in tutorial/errors.rst versions: Python 3.10, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue42179> _______________________________________

7 19