Mailman 3 March 2020 - docs

[issue39530] Documentation about comparisons between numeric types is misleading
by Mark Dickinson 04 Mar '20

04 Mar '20

New submission from Mark Dickinson <dickinsm(a)gmail.com>: The documentation[1] for comparisons between mixed types says: > [...] when a binary arithmetic operator has operands of different > numeric types, the operand with the "narrower" type is widened to > that of the other, where integer is narrower than floating point, > which is narrower than complex. Comparisons between numbers of > mixed type use the same rule. That "use the same rule" part of the last sentence is misleading: it suggests that (for example) when an int is compared with a float, the int is first converted to a float, and then the two floats are compared. But that's not what actually happens: instead, the exact values of the int and float are compared. (And it's essential that equality comparisons happen that way, else equality becomes intransitive and dictionaries with numeric keys get very confused as a result.) I suggest dropping the last sentence and adding a new paragraph about comparisons between numbers of mixed type. [1] https://github.com/python/cpython/blob/master/Doc/library/stdtypes.rst#nume… ---------- assignee: docs@python components: Documentation messages: 361234 nosy: docs@python, mark.dickinson priority: normal severity: normal status: open title: Documentation about comparisons between numeric types is misleading versions: Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue39530> _______________________________________

3 10

[issue36490] Modernize function signature format in Archiving section of shutil doc
by C.A.M. Gerlach 04 Mar '20

04 Mar '20

New submission from C.A.M. Gerlach <CAM.Gerlach(a)Gerlach.CAM>: In the process of updating the documentation for another issue, I noticed that unlike the rest of the shutil doc (and the Python docs in general, not to mention those of virtually every Python package), all the functions in the [Archiving operations section](https://docs.python.org/3/library/shutil.html#archiving-operations) uses the old style, difficult to parse nested-bracket notation for the function signatures, rather then the modern style displaying them as they would be expected to appear in Python code, with clearly and explicitly indicated defaults. Therefore, given all bracketed items are keyword arguments with defaults, and there are no cases more complex then the standard linearly-nested brackets, is there a particular reason why this was retained? Otherwise, I can go ahead and submit a PR to update this. ---------- assignee: docs@python components: Documentation messages: 339243 nosy: CAM-Gerlach, docs@python priority: normal severity: normal status: open title: Modernize function signature format in Archiving section of shutil doc versions: Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36490> _______________________________________

4 5

[issue39843] Merged fix for bpo-17560 missing from changelog
by Mikko Nylén 04 Mar '20

04 Mar '20

New submission from Mikko Nylén <mikko(a)mikkonylen.fi>: A fix for bpo-17560 (about passing very large objects between processes with multiprocessing) was merged in Nov 2018 in this PR: https://github.com/python/cpython/pull/10305 However, I see no mention of this in the changelog , even though the issue page reports the fix to be in version 3.8. Is the changelog just missing entry for this, or was the fix pulled back later and never made it's way into 3.8? ---------- assignee: docs@python components: Documentation messages: 363327 nosy: Mikko Nylén, docs@python priority: normal severity: normal status: open title: Merged fix for bpo-17560 missing from changelog type: enhancement versions: Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue39843> _______________________________________

2 1

[issue39814] Hyphens not generated for split-words in a "note" directive
by Raymond Hettinger 02 Mar '20

02 Mar '20

New submission from Raymond Hettinger <raymond.hettinger(a)gmail.com>: The justification algorithm for the docs will sometimes split words at the end of a line and will add a hyphen to indicate the continuation. This works in most text but is broken within a "note" directive. For example, there dangling "im" split of "implemenation" at the end of the third line in the note at: https://docs.python.org/3/library/functools.html#functools.total_ordering Contrast this with the correct "sup-" split of "supplies" in the first sentence. ---------- assignee: docs@python components: Documentation messages: 363075 nosy: docs@python, rhettinger priority: normal severity: normal status: open title: Hyphens not generated for split-words in a "note" directive type: behavior _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue39814> _______________________________________

3 2