Mailman 3 March 2015 - docs

[issue23559] [doc] inconsistent range example output
by Raphaël Bleuse March 2, 2015

March 2, 2015

New submission from Raphaël Bleuse: Reading the documentation for ranges (see https://docs.python.org/3.5/library/stdtypes.html#ranges), the example using a negative index output is inconsistent with the range effective behaviour. One can read: " >>> r[-1] 18 " while (in my understanding) it should be: " >>> r[-1] 8 " Note the output should be 8 and not 18. Raphaël ---------- assignee: docs@python components: Documentation messages: 237029 nosy: bleuse, docs@python … [View More]

2 1

[issue23460] Decimals do not obey ':g' exponential notation formatting rules
by Mark Dickinson March 2, 2015

March 2, 2015

Mark Dickinson added the comment: I don't think we should close: the documentation as written explicitly says that the rules apply to both Decimal and float: "The available presentation types for floating point and decimal values are ...". But the details listed for 'g' are incorrect. We could either fix the description for 'g' to explain what happens for `Decimal`, or state up front that the table only applies directly to the `float` type, and that `Decimal` is similar but not identical. --… [View More]

1 0

[issue23320] devguide should mention rules about "paragraph reflow" in the documentation
by Ezio Melotti March 2, 2015

March 2, 2015

Ezio Melotti added the comment: Agreed with what Georg said and I think the devguide can be update accordingly. ---------- assignee: -> docs@python components: +Documentation keywords: +easy nosy: +docs@python stage: -> needs patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23320> _______________________________________

1 0

[issue23460] Decimals do not obey ':g' exponential notation formatting rules
by Ezio Melotti March 2, 2015

March 2, 2015

Ezio Melotti added the comment: Should we add a note to the format docs, or just close this? ---------- nosy: +ezio.melotti, mark.dickinson _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23460> _______________________________________

1 0

[issue20521] [PATCH] Cleanup for "dis" module documentation
by Sven Berkvens-Matthijsse March 2, 2015

March 2, 2015

New submission from Sven Berkvens-Matthijsse: The documentation for the "dis" module has a wrong opcode name in it (POP_STACK instead of POP_TOP). Furthermore, the patch fixes inconsistent use of markers for code and opcodes. ---------- assignee: docs@python components: Documentation files: dis-doc.patch keywords: patch messages: 210314 nosy: docs@python, svenberkvens priority: normal severity: normal status: open title: [PATCH] Cleanup for "dis" module documentation type: behavior versions: … [View More]

5 5

[issue23484] SemLock acquire() keyword arg 'blocking' is invalid
by Davin Potts March 1, 2015

March 1, 2015

Davin Potts added the comment: To be fair, the docs in 2.7 do actually mention the use of 'block' instead of 'blocking' in acquire though it does so inside a "Note" block a bit later in the docs after first claiming that multiprocessing.Lock is a "clone". In 3.4, that important detail has been inexplicably stripped from this distended "Note" block. Ultimately, this use of the "Note" block seems to misplace important information that should appear in the description of the multiprocessing.… [View More]

1 0

[issue23484] SemLock acquire() keyword arg 'blocking' is invalid
by Davin Potts March 1, 2015

March 1, 2015

Davin Potts added the comment: In the docs for 2.7, multiprocessing.Lock refers to threading.Lock in which the signature for acquire looks like: threading.Lock.acquire([blocking]) However, in the current code in 2.7, Modules/_multiprocessing/semaphore.c implements multiprocessing.Lock.acquire to support two arguments: 'block' and 'timeout'. In the docs for 3.4, threading.Lock.acquire now has both 'blocking' and 'timeout' arguments. Notably, it specifies: "It is forbidden to specify … [View More]

1 0