Mailman 3 June 2020 - docs

[issue36783] No documentation for _FromXandFold C API functions
by Paul Ganssle 05 Jun '20

05 Jun '20

New submission from Paul Ganssle <p.ganssle(a)gmail.com>: In Python 3.6, Time_FromTimeAndFold and PyDateTime_FromDateAndTimeAndFold were added as part of the PEP 495 implementation, but no documentation was added for the C API portions of this change: https://docs.python.org/3.7/c-api/datetime.html The functions were added to this portion of the C API capsule: https://github.com/python/cpython/blob/master/Include/datetime.h#L173 Macros are here: https://github.com/python/cpython/blob/master/Include/datetime.h#L222 These functions should be documented, with `..versionadded:: 3.6` ---------- assignee: docs@python components: Documentation keywords: easy messages: 341337 nosy: docs@python, p-ganssle priority: low severity: normal status: open title: No documentation for _FromXandFold C API functions versions: Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36783> _______________________________________

6 17

[issue40868] io.TextIOBase.buffer is not necessarily a buffer
by Manuel Jacob 04 Jun '20

04 Jun '20

New submission from Manuel Jacob <me(a)manueljacob.de>: https://docs.python.org/dev/library/io.html#io.TextIOBase.buffer says: "The underlying binary buffer (a BufferedIOBase instance) that TextIOBase deals with. This is not part of the TextIOBase API and may not exist in some implementations." It is not necessarily a buffer (a BufferedIOBase instance), e.g. when the stdout and stderr streams are set to be unbuffered. Example: % python -u Python 3.8.3 (default, May 17 2020, 18:15:42) [GCC 10.1.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import io, sys >>> sys.stdout <_io.TextIOWrapper name='<stdout>' mode='w' encoding='utf-8'> >>> isinstance(sys.stdout, io.TextIOBase) True >>> sys.stdout.buffer <_io.FileIO name='<stdout>' mode='wb' closefd=False> >>> isinstance(sys.stdout.buffer, io.BufferedIOBase) False Therefore the name and the documentation are incorrect. I suggest to deprecate the attribute "buffer", introduce a new attribute with a correct name, and forward the old attribute to the new attribute and vice versa in the io.TextIOBase class. I think that "binary" would be a good attribute name for the underlying binary stream, as it would be consistent with io.BufferedIOBase.raw (for "the underlying raw stream"). ---------- assignee: docs@python components: Documentation, IO messages: 370744 nosy: docs@python, mjacob priority: normal severity: normal status: open title: io.TextIOBase.buffer is not necessarily a buffer _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue40868> _______________________________________

1 0

[issue25377] Mention octal format of mode argument of os.chmod
by Karl Richter 04 Jun '20

04 Jun '20

New submission from Karl Richter: `help(os.chmod)` doesn't explain that it expects an octal number for its `mode` argument. This is very confusing for beginners and people who are not involved with filesystems and permissions every day. It doesn't need to be explained, just mentioned, maybe with a link to an extended explanation. Example for confusion: http://stackoverflow.com/questions/15607903/python-module-os-chmodfile-664-… ---------- assignee: docs@python components: Documentation messages: 252817 nosy: docs@python, krichter priority: normal severity: normal status: open title: Mention octal format of mode argument of os.chmod type: enhancement versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25377> _______________________________________

5 5

[issue40850] Programming FAQ - variables local to the lambdas
by Rainald Koch 03 Jun '20

03 Jun '20

New submission from Rainald Koch <Rainald.Koch(a)t-online.de>: In section [10] of the FAQ, I whould add "(a function parameter with different default values)" after "variables local to the lambdas". Besides, I had to look up "memoizing" [2] and suspect that "memorizing" would be correct. [10] https://docs.python.org/3/faq/programming.html#why-do-lambdas-defined-in-a-… [2] https://en.wikipedia.org/wiki/Memoization ---------- assignee: docs@python components: Documentation messages: 370637 nosy: Rainald Koch, docs@python priority: normal severity: normal status: open title: Programming FAQ - variables local to the lambdas type: enhancement versions: Python 3.10 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue40850> _______________________________________

3 2

[issue31517] MainThread association logic is fragile
by STINNER Victor 03 Jun '20

03 Jun '20

Change by STINNER Victor <vstinner(a)python.org>: ---------- components: +Subinterpreters _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue31517> _______________________________________

1 0

[issue40846] Misleading line in documentation
by J Arun Mani 03 Jun '20

03 Jun '20

New submission from J Arun Mani <j.arunmani(a)protonmail.com>: Hi. In docs : https://docs.python.org/3/faq/programming.html#faq-argument-vs-parameter it says "Parameters define what types of arguments a function can accept." This is not true. Python's functions do not impose any type checking or raise error when the argument's type is not matching it's type hint. Please change the line to a better one. Maybe "Parameters define the names that will hold the supplied arguments." Thanks ^^ ---------- assignee: docs@python components: Documentation messages: 370616 nosy: J Arun Mani, docs@python priority: normal severity: normal status: open title: Misleading line in documentation _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue40846> _______________________________________

4 5

problem with upper method
by გიორგი კაკულაშვილი 02 Jun '20

02 Jun '20

Hi, I want to report about bug with string.upper() method. In Georgian we don't have uppercase letters, so for example ord("ე".upper()) returns 7316, which is not a letter. I found this bug in my Django project, first letters of form labels where all wrong, when I started looking for the reason, I found that they are using upper method. In python3.6 upper method works correctly with Georgian letters, but in python3.8 it has bug.

2 1

[issue23557] Misc/SpecialBuilds.txt contains outdated information about PYMALLOC_DEBUG
by Jakub Klama 01 Jun '20

01 Jun '20

New submission from Jakub Klama: Section describing block layout under PYMALLOC_DEBUG is wrong - it doesn't contain information about API type byte instead of one of forbidden bytes. That may lead to wrong assumption that one of forbidden bytes is being overwritten until you dig into obmalloc.c code. ---------- assignee: docs@python components: Documentation, Interpreter Core messages: 236958 nosy: Jakub Klama, docs@python priority: normal severity: normal status: open title: Misc/SpecialBuilds.txt contains outdated information about PYMALLOC_DEBUG versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23557> _______________________________________

3 2

[issue24921] Operator precedence table in 5.15 should be highest to lowest precedence
by Joseph Schachner 01 Jun '20

01 Jun '20

New submission from Joseph Schachner: We should not make people who need to read Python documentation do an extra transformation in their heads to correctly understand that in section 5.15 higher precedence is at the bottom of the table and lower precedence is at the top. Because the documentation has this table inverted from the way it is usually presented in other references, one of the top hits in a Google search shows an instructor felt the need to make a version in the usual "high to low precedence" order to show students, see: http://www.mathcs.emory.edu/~valerie/courses/fall10/155/resources/op_preced… That version is so much more comfortable for me to read, it seems almost strange, but it is true. Please consider changing section 5.15 so it would not need the top paragraph explaining that the table order is not what the reader probably expects, instead just present the table as at the link above - in the order the reader does expect - higher precedence on top, lower on the bottom. That only needs two short sentences of explanation that don't make the reader think "wait ... what?" ---------- assignee: docs@python components: Documentation messages: 249046 nosy: Joseph Schachner, docs@python priority: normal severity: normal status: open title: Operator precedence table in 5.15 should be highest to lowest precedence versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue24921> _______________________________________

6 6