Mailman 3 April 2015 - docs

[issue23913] error in some byte sizes of docs in array module
by Boyd Blackwell April 11, 2015

April 11, 2015

New submission from Boyd Blackwell: See 8.6. array — Efficient arrays of numeric values¶ I think these two table entries should list 4 instead of 2, at least for 64 python. The error is currently in 2.710rc0, but also in previous versions. also in 3.4.3, presumably some previous versions it might also be argued that the column heading should not but minimum size but simply Element Size (bytes) 'i' signed int int 2 'I' unsigned int long 2 code: import array a = array.array('I') a.fromstring('\x01\x02\x03\x04') print(a) #array('I', [67305985L]) # one element as expected (4 bytes, 4 bytes/elt) a = array.array('H') a.fromstring('\x01\x02\x03\x04') print(a) #array('H', [513, 1027]) # two elements as expected (4 bytes, 2 bytes/elt) ---------- assignee: docs@python components: Documentation files: arraydocbug.py messages: 240466 nosy: bdb112, docs@python priority: normal severity: normal status: open title: error in some byte sizes of docs in array module versions: Python 2.7 Added file: http://bugs.python.org/file38897/arraydocbug.py _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23913> _______________________________________

3 2

[issue23912] Inconsistent whitespace/formatting in docs/reference/datamodel/Special Method Lookup
by James Edwards April 11, 2015

April 11, 2015

New submission from James Edwards: There's inconsistent leading whitespace between the two classes in the 4th code snippet of the "Special Method Lookup" section. https://docs.python.org/3/reference/datamodel.html#special-method-lookup The (very substantial :) included patch makes both classes use consistent leading whitespace, that is PEP-8 conformant. (This issue also exists in the Python 2 documentation[1], but since other things have changed -- e.g. print statement -> function, metaclass declaration -- the same patch won't apply cleanly.) [1] https://docs.python.org/2/reference/datamodel.html#special-method-lookup-fo… ---------- assignee: docs@python components: Documentation files: datamodel.rst.diff keywords: patch messages: 240458 nosy: docs@python, jedwards priority: normal severity: normal status: open title: Inconsistent whitespace/formatting in docs/reference/datamodel/Special Method Lookup versions: Python 3.6 Added file: http://bugs.python.org/file38894/datamodel.rst.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23912> _______________________________________

3 2

[issue23909] highlight query string does not work on docs.python.org/2
by Mark Mikofski April 11, 2015

April 11, 2015

New submission from Mark Mikofski: expected: using Sphinx search in docs, search keyword is usually highlighted on resulting pages. observerd: query string ?highligh=<string> does nothing on http://docs.python.org/2 although it actually does work for 2.6 and all 3.x docs. Doesn't appear to be a function of Sphinx version as 3.x docs and 2.7.x docs all use Sphinx-1.2.3 examples: works: https://docs.python.org/3/tutorial/appetite.html?highlight=indent does'nt: https://docs.python.org/2/tutorial/appetite.html?highlight=indent platform: works? chrome: no firefox: no ---------- assignee: docs@python components: Documentation messages: 240443 nosy: bwanamarko, docs@python priority: normal severity: normal status: open title: highlight query string does not work on docs.python.org/2 versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23909> _______________________________________

2 1

[issue23025] ssl.RAND_bytes docs should mention os.urandom
by Alex Gaynor April 10, 2015

April 10, 2015

New submission from Alex Gaynor: For almost any conceivable application, os.urandom is a preferable way to access a CSPRNG, and is less error prone, the docs should point this out. ---------- assignee: docs@python components: Documentation files: rand.diff keywords: patch messages: 232436 nosy: alex, docs@python priority: normal severity: normal status: open title: ssl.RAND_bytes docs should mention os.urandom Added file: http://bugs.python.org/file37410/rand.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23025> _______________________________________

6 7

[issue12160] codecs doc: what is StreamCodec?
by R. David Murray April 9, 2015

April 9, 2015

Changes by R. David Murray <rdmurray(a)bitdance.com>: ---------- stage: patch review -> commit review _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12160> _______________________________________

1 0

[issue19247] Describe surrogateescape algorithm in the Library Reference
by Nick Coghlan April 9, 2015

April 9, 2015

Nick Coghlan added the comment: The last round of updates to the codecs module docs covered the relevant details in the new error handlers section: https://docs.python.org/3/library/codecs.html#error-handlers ---------- resolution: -> fixed stage: needs patch -> resolved status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue19247> _______________________________________

1 0

Pb de d'essai du code à la section 7.2.1 Methods Of File Objects
by Vincent . April 9, 2015

April 9, 2015

Bonjour, Quand j'exécute le code suivant (tiré du manuel section 7.2.1): f = open('workfile', 'r') f.read() Celui-ci fonctionne sous l'interpréteur, mais pas quand le même code est mis dans un fichier. Merci de proposer une solution (celle-ci sera employé par tout lecteur de la documentation) à ce problème. Vincent. -------------------------------------------------------------------------------------------------- Hello, When I run this code f = open('workfile', 'r') f.read() under python interpreter, it operate. in a file, it doesn't work Please, help to fix this bug which be useful for all readers of your docs. Vincent.

2 2

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

April 8, 2015

Davin Potts added the comment: Same for 2.7 branch. ---------- Added file: http://bugs.python.org/file38868/issue_23484_doc_locks_py27_noverchange.pat… _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23484> _______________________________________

1 0

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

April 8, 2015

Davin Potts added the comment: Updating patch for default/3.5 and 3.4 branches to remove versionchanged message on {Lock,RLock}.acquire per feedback from @berker. ---------- Added file: http://bugs.python.org/file38867/issue_23484_doc_locks_py35_and_py34_noverc… _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23484> _______________________________________

1 0

Re: [docs] SemLock acquire() keyword arg 'blocking' is invalid (issue 23484)
by python＠discontinuity.net April 8, 2015

April 8, 2015

Hi Berker -- Unrelated to this but thanks also for finishing off issue23400 today. Davin https://bugs.python.org/review/23484/diff/14347/Doc/library/multiprocessing… File Doc/library/multiprocessing.rst (right): https://bugs.python.org/review/23484/diff/14347/Doc/library/multiprocessing… Doc/library/multiprocessing.rst:1199: .. versionchanged:: 2.7 Looking back through the prior branches, it turns out the timeout parameter was introduced in 2.6 (same branch where multiprocessing itself was introduced) and it is present in 3.0 upwards too. Unfortunately I trusted or misinterpreted the docs that suggested otherwise -- makes your reacting to this an especially good catch. I think the right thing to do is to remove the versionchanged line altogether since both 'block' and 'timeout' have been there pretty much since the beginning. I'll make that quick change and update the patch files. On 2015/04/02 18:00:10, davin wrote: > On 2015/04/01 17:36:10, berkerpeksag wrote: > > If the timeout parameter was added in 2.7 and 3.0, we can remove this > directive > > on 3.4 and default branches since it's there for the beginning of Python 3. > > > > On the other hand, for example, if it was added in 2.7 and 3.2, we should > change > > it to .. versionchanged:: 3.2 in Python 3 documentation. > > Makes sense -- I will double-check when it got added to Python 3 and make that > change. > > My thinking was that bringing attention to this, even if it has been there for a > while, is a good thing because this is the first time it's been reflected in the > documentation. But if your immediate reaction is that this looks weird (coming > from 2.7 or 3.0), then my idea was the wrong way to go. https://bugs.python.org/review/23484/

1 0