Mailman 3 May 2020 - docs

[issue38580] select()'s documentation claims only sequences are accepted, but it allows all iterables
by Tal Einat May 26, 2020

May 26, 2020

Change by Tal Einat <taleinat+python(a)gmail.com>: ---------- pull_requests: +19684 pull_request: https://github.com/python/cpython/pull/20426 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue38580> _______________________________________

1 0

[issue38580] select()'s documentation claims only sequences are accepted, but it allows all iterables
by Tal Einat May 26, 2020

May 26, 2020

Change by Tal Einat <taleinat+python(a)gmail.com>: ---------- pull_requests: +19682 pull_request: https://github.com/python/cpython/pull/20424 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue38580> _______________________________________

1 0

[issue40719] Add pt-br to the language switcher at the Python 3.6 and 2.7 docs website
by Rafael Fontenelle May 26, 2020

May 26, 2020

New submission from Rafael Fontenelle <rffontenelle(a)gmail.com>: Thanks to bpo-38592, pt-br is listed in 3.8 and 3.7 versions. Now, pt-br team's repository has 3.6 and 2.7 branches daily pomerged from 3.8 branch. So, I believe it would nice to have it in those older versions' language switcher. ---------- assignee: docs@python components: Documentation messages: 369540 nosy: docs@python, rffontenelle priority: normal severity: normal status: open title: Add pt-br to the language switcher at the Python 3.6 and 2.7 docs website type: enhancement versions: Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue40719> _______________________________________

1 2

[issue35714] Document that the null character '\0' terminates a struct format spec
by Dan Snider May 26, 2020

May 26, 2020

New submission from Dan Snider <mr.assume.away(a)gmail.com>: ie.: >>> from struct import calcsize >>> calcsize('\144\u0064\000xf\U00000031000\60d\121\U00000051') 16 I'm sure some people think it's obvious or even expect the null character to signal EOF but it probably isn't obvious at all to those without experience in lower level languages. It actually seems like Python goes out of its way to make sure everything treats the null character no more special than the letter "H", which is good. At first glance I'd think something like this was just another trivial quirk of the language and not bring it up, but because the documentation doesn't mention it I actually got stuck on something related for half an hour when unit testing some dynamically generated format specs. Without going into unnecessary detail, what happened was that a typo in another tangentially related part of the test was enabling the generation of a rogue null byte. I'm bad at those "find face in the crowd" puzzles and this was hardly different, being literally camouflaged within a 300 character format spec containing a random mixture of escaped and non-escaped source characters in the forms: \Uffffffff, \uffff, \777, \xff, \x00, + latin/ascii. If I'm not the only one who sees this as a slightly bigger deal than poor documentation, the fix is trivial with an extra call to PyBytes_GET_SIZE when null is found. But just because I can't think of a use case in allowing the null character to precede other characters in the format string doesn't mean there isn't one, which is why only documentation is currently selected. ---------- assignee: docs@python components: Documentation, Library (Lib) messages: 333424 nosy: bup, docs@python priority: normal severity: normal status: open title: Document that the null character '\0' terminates a struct format spec versions: Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue35714> _______________________________________

6 16

[issue39301] Specification of bitshift on integers should clearly state floor division used
by Nick Coghlan May 26, 2020

May 26, 2020

New submission from Nick Coghlan <ncoghlan(a)gmail.com>: While reviewing ISO-IECJTC1-SC22-WG23's latest draft of their Python security annex, I noticed that https://docs.python.org/3.7/library/stdtypes.html#bitwise-operations-on-int… doesn't explicitly state that *floor* division is used for right shift operations, so right-shifting a negative number by more bits than it contains gives -1 rather than 0. This is consistent with the way the language spec defines both binary right-shifts (as division by "pow(2, n)" and floor division (as rounding towards negative infinity), so this is just a documentation issue to note that we should make it clearer that this behaviour is intentional. ---------- assignee: docs@python components: Documentation messages: 359786 nosy: docs@python, ncoghlan priority: normal severity: normal stage: needs patch status: open title: Specification of bitshift on integers should clearly state floor division used type: enhancement versions: Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue39301> _______________________________________

4 15

[issue40774] "Important" block in documentation of asyncio.create_subprocess_shell() not indented correctly
by Stephan Hohe May 25, 2020

May 25, 2020

New submission from Stephan Hohe <sth.dev(a)tejp.de>: The [documentation][1] for asyncio.create_subprocess_shell() contains an "important" block about quoting special characters. This block and the following deprecation note belong to this specific function, but are not correctly indented and shown at module level. [1]: https://docs.python.org/3.10/library/asyncio-subprocess.html#asyncio.create… ---------- assignee: docs@python components: Documentation messages: 369930 nosy: docs@python, sth priority: normal severity: normal status: open title: "Important" block in documentation of asyncio.create_subprocess_shell() not indented correctly versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue40774> _______________________________________

3 6

[issue40558] update CONTRIBUTING.rst docs
by hai shi May 25, 2020

May 25, 2020

New submission from hai shi <shihai1991(a)126.com>: update the links of buildbot in CONTRIBUTING.rst. I don't know why I can not visit `http://buildbot.python.org/3.8.stable/` ---------- assignee: docs@python components: Documentation messages: 368422 nosy: docs@python, shihai1991 priority: normal severity: normal status: open title: update CONTRIBUTING.rst docs versions: Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue40558> _______________________________________

3 6

[issue40748] Tutorial 4.7 More on Defining Functions missing screen prompts
by Chas Belov May 25, 2020

May 25, 2020

New submission from Chas Belov <docorbit(a)sonic.net>: The tutorial on More on Defining Functions at https://docs.python.org/3.7/tutorial/controlflow.html#more-on-defining-func… is missing most of the >>> and ... screen prompts that show elsewhere in the tutorial. This is potentially confusing to readers. I am going to attempt a PR by May 26, 2020. ---------- assignee: docs@python components: Documentation messages: 369753 nosy: Chas Belov, docs@python priority: normal severity: normal status: open title: Tutorial 4.7 More on Defining Functions missing screen prompts 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/issue40748> _______________________________________

3 8

Please update PEP 596 with the list of new features in Python 3.9 (at last)
by Mikhail Golubev May 25, 2020

May 25, 2020

Hi there! First of all, sorry if it's not the right mailing list to ask about it. I'm not sure which of them covers changes in such PEP documents. These "Release Schedule" informational PEPs used to be a handy concise reference of which feature PEPs are scheduled for a particular language version. Now, as Python 3.9 is in development, this information has to be recollected from dev documentation/mailing lists/newsletters/twits, etc. It can get confusing at times since not every accepted PEP ultimately goes into the next language version. Please keep them up to date, they are very helpful.

2 2

Helping in translation to portuguese
by Yuri Alexandre Aoto May 25, 2020

May 25, 2020

Dear Python developers/doc maintainers, I am interested on helping to translate the docs (https://docs.python.org/3/) to Brazilian Portuguese. I see that there are several pages and topics that are just partially translated. Although I cannot spend full time on this, I use the docs often and I think I could just translate the parts that I happen to use and post it. How can I do that? Thank you, Yuri

2 2