Mailman 3 April 2021 - docs

[issue43721] Documentation of property.{getter, setter, deleter} fails to mention that a *new* property is returned
by Antony Lee 04 Apr '21

04 Apr '21

New submission from Antony Lee <anntzer.lee(a)gmail.com>: property.{getter,setter,deleter} returns a new property with a new {fget,fset,fdel}. This is documented at https://docs.python.org/3/library/functions.html#property, and intended behavior (see e.g. https://bugs.python.org/issue1620). However the corresponding docstrings, e.g. `pydoc property.getter`, are "Descriptor to change the getter (setter, deleter) on a property." This wording suggests that no copy is being made and that the property is mutated in-place. ---------- assignee: docs@python components: Documentation messages: 390149 nosy: Antony.Lee, docs@python priority: normal severity: normal status: open title: Documentation of property.{getter,setter,deleter} fails to mention that a *new* property is returned _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue43721> _______________________________________

2 2

[issue43705] Document that SyntaxError's offsets are 1-indexed
by Ammar Askar 03 Apr '21

03 Apr '21

New submission from Ammar Askar <ammar(a)ammaraskar.com>: As pointed out by Guido in https://bugs.python.org/issue43555, we switched to making the column offsets for SyntaxError be 1-indexed consistently in https://bugs.python.org/issue34683 The rationale is explained by Guido and expanded upon in follow up comments here: https://github.com/python/cpython/pull/9338#pullrequestreview-155989089 This property however was not actually ever added to SyntaxError's documentation: https://docs.python.org/3/library/exceptions.html#SyntaxError ---------- assignee: docs@python components: Documentation messages: 390081 nosy: ammar2, docs@python, gvanrossum, terry.reedy priority: normal severity: normal status: open title: [docs] Document that SyntaxError's offsets are 1-indexed versions: Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue43705> _______________________________________

3 8

[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal
by Steve Dower 03 Apr '21

03 Apr '21

Steve Dower <steve.dower(a)python.org> added the comment: (Copied from my comment on the PR, following the one where I said this was ready to go.) Withdrawing the readiness - @ambv and I would prefer to see this behind a flag (probably "strict" parsing), on by default for 3.10, and maybe on by default for 3.9/earlier. The main reasoning being that this isn't our vulnerability, but an inconsistency with other vulnerable libraries. The current fix is the best it can be, but it doesn't prevent the vulnerability, it just causes Python to break first. So it ought to be relatively easy to retain the flexible (though admittedly non-sensical) behaviour for those who currently rely on it. ---------- nosy: +steve.dower _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36384> _______________________________________

1 0

[issue43713] sorted() signature is not accurate in the documentation
by Tomer Kalish 03 Apr '21

03 Apr '21

New submission from Tomer Kalish <tomer.kalish91(a)gmail.com>: According to the docs, the sorted function's signature is: sorted(iterable, *, key=None, reverse=False) But when printing its help interactively, the signature is: sorted(iterable, /, *, key=None, reverse=False) The latter seems to be the correct one, as calling sorted(iterable=arr) will raise a TypeError. The signature in the docs should be fixed. ---------- assignee: docs@python components: Documentation messages: 390122 nosy: docs@python, tomer.kalish91 priority: normal severity: normal status: open title: sorted() signature is not accurate in the documentation type: resource usage versions: Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue43713> _______________________________________

2 1

[issue41283] The parameter name for imghdr.what in the documentation is wrong
by Adam Eltawla 02 Apr '21

02 Apr '21

New submission from Adam Eltawla <bekerpico(a)gmail.com>: I noticed the parameter name for imghdr.what in the documentation is wrong Link: https://docs.python.org/3.8/library/imghdr.html?highlight=imghdr function imghdr.what(filename, h=None) In reality: def what(file, h=None): It is 'file' not 'filename'. ---------- assignee: docs@python components: Documentation messages: 373551 nosy: aeltawela, docs@python priority: normal severity: normal status: open title: The parameter name for imghdr.what in the documentation is wrong type: enhancement versions: Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue41283> _______________________________________

3 4

[issue40932] subprocess docs don't qualify the instruction to use shlex.quote by OS
by Stephen Farris 02 Apr '21

02 Apr '21

New submission from Stephen Farris <stephen.farris(a)jhuapl.edu>: The subprocess docs state: "When using shell=True, the shlex.quote() function can be used to properly escape whitespace and shell metacharacters in strings that are going to be used to construct shell commands." While this is true on Unix, it is not true on Windows. On Windows it is easy to create scenarios where shell injection still exists despite using shlex.quote properly (e.g. subprocess.run(shlex.quote("'&calc '"), shell=True) launches the Windows calculator, which it wouldn't do if shlex.quote was able to prevent shell injection on Windows). While the shlex docs state that shlex is for Unix, the subprocess docs imply that shlex.quote will work on Windows too, possibly leading some developers to erroneously use shlex.quote on Windows to try to prevent shell injection. Recommend: 1) qualifying the above section in the subprocess docs to make it clear that this only works on Unix, and 2) updating the shlex docs with warnings that shlex.quote in particular is not for use on Windows. ---------- assignee: docs@python components: Documentation messages: 371140 nosy: Stephen Farris, docs@python priority: normal severity: normal status: open title: subprocess docs don't qualify the instruction to use shlex.quote by OS versions: Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue40932> _______________________________________

6 8

[issue34398] Docs search does not index glossary
by Jonathan Fine 02 Apr '21

02 Apr '21

New submission from Jonathan Fine <jfine2358(a)gmail.com>: The docs contain a very useful page https://docs.python.org/3.5/glossary.html. However, the search feature does not index the glossary. Thus, the search https://docs.python.org/3.5/search.html?q=iterable does not produce the helpful glossary entry === iterable An object capable of returning its members one at a time. Examples of iterables include all sequence types (such as list, str, and tuple) and some non-sequence types like dict, file objects, and objects of any [...] === #788509 is the only docs issue I could find, whose title contains glossary. It gives insight into the thoughts then about the tutorial. In msg44460 Skip Montaro says (1) that the glossary is "for the tutorial", and (2) he'd like to improve links into the tutorial. I suggest that part of the fix for this issue is on the home page page Glossary in the first grouping "Parts of the documentation." ---------- assignee: docs@python components: Documentation messages: 323503 nosy: docs@python, jfine2358 priority: normal severity: normal status: open title: Docs search does not index glossary type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue34398> _______________________________________

6 12

[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal
by Łukasz Langa 02 Apr '21

02 Apr '21

Łukasz Langa <lukasz(a)langa.pl> added the comment: Deferred the blocker to the next regular release due to lack of activity in time for the current expedited releases. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36384> _______________________________________

1 0

[issue36384] ipaddress Should not reject IPv4 addresses with leading zeroes as ambiguously octal
by Łukasz Langa 02 Apr '21

02 Apr '21

Change by Łukasz Langa <lukasz(a)langa.pl>: ---------- priority: release blocker -> deferred blocker _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36384> _______________________________________

1 0

[issue43700] Replace Zulip badge with Discourse badge in README
by Erlend Egeberg Aasland 02 Apr '21

02 Apr '21

New submission from Erlend Egeberg Aasland <erlend.aasland(a)innova.no>: Suggesting to follow the dev guide and replace the Zulip badge with a Discourse badge in README.rst. Quoting the dev guide, section 2.4. Zulip: "This is no longer actively monitored by core devs. Consider asking your questions on Discourse or on the python-dev mailing list." See also: - https://python.zulipchat.com - https://devguide.python.org/help/#zulip - https://discuss.python.org/t/discourse-github-integration/355 - https://github.com/python/devguide/issues/625 - https://github.com/python/devguide/pull/630 ---------- assignee: docs@python components: Documentation messages: 390016 nosy: Mariatta, docs@python, erlendaasland, willingc priority: normal severity: normal status: open title: Replace Zulip badge with Discourse badge in README _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue43700> _______________________________________

3 7