Mailman 3 December 2016 - docs

reference doc problem
by Christopher Barry Jan. 2, 2017

Jan. 2, 2017

https://docs.python.org/3.5/reference/lexical_analysis.html#keywords describes 'is' as a keyword, yet https://docs.python.org/3.5/reference/datamodel.html#objects-values-and-typ… describes 'is' as an operator. Which is it? If it really is an operator (too?), shouldn't it be here: https://docs.python.org/3.5/reference/lexical_analysis.html#operators as well? -- Regards, Christopher Barry

2 1

[issue26267] UUID docs should say how to get "standard form"
by Andrew Barnert Dec. 31, 2016

Dec. 31, 2016

New submission from Andrew Barnert: Most real-world code that uses the UUID module wants either the standard format '{12345678-1234-5678-1234-567812345678}', or the same thing without the braces. There are a number of different documented accessors, but none of them give you either of these. The simplest way I can think of to guarantee the standard format from what's documented is '{%08x-%04x-%04x-%02x%02x-%12x}' % u.fields. It might be nice to add accessors for standard form and braceless standard form, but that probably isn't necessary--as long as there's documentation saying that __str__ returns the braceless standard form. The example code does say that, but I don't think people can trust that a comment in an example is binding documentation--plus, plenty of people don't read the examples looking for more information about things that aren't documented. And I've seen people come up with buggy versions of the format string that miss leading zeros, or horrible things like repr(u)[6:42]. ---------- assignee: docs@python components: Documentation messages: 259414 nosy: abarnert, docs@python priority: normal severity: normal status: open title: UUID docs should say how to get "standard form" type: enhancement _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue26267> _______________________________________

7 17

[issue29105] code or doc improvement for logging.handlers.RotatingFileHandler
by iMath Dec. 31, 2016

Dec. 31, 2016

New submission from iMath: For class logging.handlers.RotatingFileHandler(filename, mode='a', maxBytes=0, backupCount=0, encoding=None, delay=0) if backupCount is zero and maxBytes is non-zero, the log file size could exceed maxBytes, i.e. we are not able to restrict the log file size using RotatingFileHandler at this case . I suggest add the above description to the doc https://docs.python.org/3.6/library/logging.handlers.html#logging.handlers.… If possible , set backupCount=1 by default to avoid this pitfall as much as possible. The doc right now just says "if either of maxBytes or backupCount is zero, rollover never occurs.", it is too difficult to understand the meaning of 'Rollover' to aviod the pitfall . ---------- assignee: docs@python components: Documentation messages: 284277 nosy: docs@python, redstone-cold priority: normal severity: normal status: open title: code or doc improvement for logging.handlers.RotatingFileHandler type: enhancement versions: Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue29105> _______________________________________

3 2

[issue28816] Document if zipimport can respect import hooks to load custom files from zip.
by Decorater Dec. 30, 2016

Dec. 30, 2016

Decorater added the comment: OK, Well I just tested and it sadly don't support import hooks that adds support for importing custom file types or file types python does know about with a uncommon extension inside of zip files which is somewhat sad. However if someone was to do something similar to py2exe's import hook allowing memory loading pyd and so files they could allow it to work for their import hook's needs. ---------- keywords: +patch Added file: http://bugs.python.org/file46090/zipimport.rst.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue28816> _______________________________________

1 0

[issue29089] Python 2 dictionary keys described incorrectly
by Xezlec Dec. 30, 2016

Dec. 30, 2016

New submission from Xezlec: In section 5.5 on the page https://docs.python.org/2/tutorial/datastructures.html#dictionaries the requirements given for dictionary keys are not correct. Specifically, it is claimed that only immutable objects (and tuples containing only immutable objects) may be used as keys. This is false, as user-defined mutable objects may be used as keys. I suggest rewording along these lines: "Only user-defined objects and immutable built-in types may be used as keys. Although allowed, it is bad practice to use a mutable user-defined object as a key when equality is determined in any way other than identity (the default)." ---------- assignee: docs@python components: Documentation messages: 284135 nosy: Xezlec, docs@python priority: normal severity: normal status: open title: Python 2 dictionary keys described incorrectly versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue29089> _______________________________________

4 9

[issue29112] questionable wording in sequences documentation
by Jesse Hall Dec. 30, 2016

Dec. 30, 2016

New submission from Jesse Hall: In note 3 of 4.6.1, the word "string" should be replaced with "sequence", because the note is describing a general example where this concept is not specifically used with a string type sequence, it is discussing the general use of negative indexes which can be used on any type of sequence. ---------- assignee: docs@python components: Documentation messages: 284303 nosy: Jesse Hall, docs@python priority: normal severity: normal status: open title: questionable wording in sequences documentation versions: Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue29112> _______________________________________

3 2

[issue29109] Small doc improvements for tracemalloc
by Loic Pefferkorn Dec. 30, 2016

Dec. 30, 2016

New submission from Loic Pefferkorn: Hello, I believe that some improvements can be made to the Python 3.4 documentation of the tracemalloc module: * Wrong parameter name, 'group_by' instead of 'key_type' (checked in tracemalloc.py) * Don't round up numbers when explaining the examples. If they exactly match what can be read in the script output, it is to easier to understand (4.8 MiB vs 4855 KiB) * Fix incorrect method link that was pointing to another module I will wait for some feedback before checking the 3.5, 3.6 versions, hopefully I did not forget something :) Cheers, Loic ---------- assignee: docs@python components: Documentation files: doc_3.4_tracemalloc.diff keywords: patch messages: 284298 nosy: docs@python, haypo, loicp priority: normal severity: normal status: open title: Small doc improvements for tracemalloc type: enhancement versions: Python 3.4 Added file: http://bugs.python.org/file46086/doc_3.4_tracemalloc.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue29109> _______________________________________

3 2

[issue28978] a redundant right parentheses in the EBNF rules of parameter_list
by woo yoo Dec. 29, 2016

Dec. 29, 2016

New submission from woo yoo: Quote the documentation as below: > parameter_list ::= (defparameter ",")* | "*" [parameter] ("," defparameter)* ["," "**" parameter] | "**" parameter | defparameter [","] ) The last right parenthesis is redundant.And the second alternative form is not complete, it does not incorporate a case that only include starred parameter. ---------- assignee: docs@python components: Documentation messages: 283288 nosy: docs@python, woo yoo priority: normal severity: normal status: open title: a redundant right parentheses in the EBNF rules of parameter_list versions: Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue28978> _______________________________________

4 13

Bug in Path from pathlib
by Lil' Drummer Boy Dec. 29, 2016

Dec. 29, 2016

Hi, Going through the basics at https://docs.python.org/3/library/pathlib.html , I encountered an issue. In Basic Use, 11.1.1, Querying Path Properties: , for some reason the answer was false whenever q.exists() was typed in the python 3.6.0 interpreter. Any help would be appreciated. Thanks, Mike

1 0

[issue29087] UCS4 support functions are not implemented
by Serhiy Storchaka Dec. 28, 2016

Dec. 28, 2016

New submission from Serhiy Storchaka: There is a special section in the documentation of Unicode Objects C API: UCS4 Support. https://docs.python.org/3/c-api/unicode.html#ucs4-support It documents utility functions that work on strings of Py_UCS4 characters like Py_UCS4_strlen(), Py_UCS4_strcpy(), etc. But none of these functions is implemented. May be the documentation should be just removed? ---------- assignee: docs@python components: Documentation, Unicode messages: 284126 nosy: benjamin.peterson, docs@python, ezio.melotti, haypo, lemburg, serhiy.storchaka priority: normal severity: normal status: open title: UCS4 support functions are not implemented type: behavior versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue29087> _______________________________________

3 4