Mailman 3 May 2019 - docs

[issue36947] Fix 3.3.3.1 Metaclasses Documentation
by Stéphane Wirtel May 17, 2019

May 17, 2019

Stéphane Wirtel <stephane(a)wirtel.be> added the comment: Thank you for your report ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python, matrixise _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36947> _______________________________________

1 0

[issue19175] Erroneous reference to "integer" in format string grammar
by David Chambers May 17, 2019

May 17, 2019

New submission from David Chambers: I first raised this issue on Stack Overflow: http://stackoverflow.com/questions/19203194 The [replacement field grammar][1] states that an [integer][2] is a valid field_name, but this is inaccurate: >>> '{0}'.format('zero') 'zero' >>> '{0x0}.format('zero') KeyError: '0x0' >>> '{0o0}.format('zero') KeyError: '0o0' >>> '{0b0}.format('zero') KeyError: '0b0' This [comment][3] by Eric Smith suggests that the above is the intended behaviour: > get_integer uses the narrowest possible definition for integer indexes, > in order to pass all other strings to mappings. The documentation should be updated to match the actual behaviour. abarnert on Stack Overflow suggested the following change: -arg_name ::= [identifier | integer] +arg_name ::= [identifier | digit+] [1]: http://docs.python.org/2/library/string.html#format-string-syntax [2]: http://docs.python.org/2/reference/lexical_analysis.html#grammar-token-inte… [3]: http://bugs.python.org/issue8985#msg107705 ---------- assignee: docs@python components: Documentation messages: 199024 nosy: davidchambers, docs@python priority: normal severity: normal status: open title: Erroneous reference to "integer" in format string grammar versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue19175> _______________________________________

3 3

[issue10669] Document Deprecation Warnings and how to fix
by Cheryl Sabella May 17, 2019

May 17, 2019

Cheryl Sabella <cheryl.sabella(a)gmail.com> added the comment: If this is change is still desirable, I think it might be a good issue for someone who had contributed a few patches and is looking for something a little more challenging to work on. ---------- nosy: +cheryl.sabella, mdk, willingc stage: -> needs patch versions: +Python 3.8 -Python 2.7, Python 3.2, Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue10669> _______________________________________

1 0

[issue36789] Unicode HOWTO incorrectly states that UTF-8 contains no zero bytes
by mbiggs May 17, 2019

May 17, 2019

New submission from mbiggs <pythonbugs(a)doubleplum.net>: In the Unicode HOWTO: http://docs.python.org/3.3/howto/unicode.html It says the following: "UTF-8 has several convenient properties: (...) 2. A Unicode string is turned into a sequence of bytes containing no embedded zero bytes. This avoids byte-ordering issues, and means UTF-8 strings can be processed by C functions such as strcpy() and sent through protocols that can’t handle zero bytes." This is not right. UTF-8 uses the zero byte to represent the Unicode codepoint U+0000 (the ASCII NULL character). This is a valid character in UTF-8 and is handled just fine by python's UTF-8 string encoding/decoding. ---------- assignee: docs@python components: Documentation messages: 341363 nosy: docs@python, mbiggs priority: normal severity: normal status: open title: Unicode HOWTO incorrectly states that UTF-8 contains no zero bytes versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36789> _______________________________________

8 10

[issue36928] linkt threading.settrace to sys.settrace
by Stefan Hölzl May 17, 2019

May 17, 2019

New submission from Stefan Hölzl <stefan.la(a)posteo.de>: The documentation of sys.settrace suggest to call it from every created thread to enable tracing within threads. I would suggest to add a link to threading.settrace which automatically sets a trace function for every by threading module created thread. link to docs: https://docs.python.org/3.5/library/sys.html#sys.settrace https://docs.python.org/3.5/library/threading.html#threading.settrace ---------- assignee: docs@python components: Documentation messages: 342591 nosy: docs@python, stefanhoelzl priority: normal severity: normal status: open title: linkt threading.settrace to sys.settrace versions: Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36928> _______________________________________

4 5

[issue36927] traceback docstrings should explicitly state return values instead of referring to other functions
by Aaron Hall May 16, 2019

May 16, 2019

New submission from Aaron Hall <aaronchall(a)yahoo.com>: I've written three (or more) answers on Stack Overflow about how to use the functions in the traceback module, and I code Python all day long. Embarrassing confession: I just recommended the wrong traceback function in email to fix the incorrect usage of another of these functions after pulling up the docs because. I corrected myself before anyone else could correct me, but I find these docstrings incredibly frustrating and problematic. May I please give them a little more verbiage about their return values? e.g.: def format_tb(tb, limit=None): """A shorthand for 'format_list(extract_tb(tb, limit))'.""" return extract_tb(tb, limit=limit).format() should be: def format_tb(tb, limit=None): """A shorthand for 'format_list(extract_tb(tb, limit))', which returns a list of strings ready for printing'. """ return extract_tb(tb, limit=limit).format() In fact, perhaps the "shorthand" part is an implementation detail that may not even be correct (it doesn't immediately seem to be) and should be removed. ---------- assignee: docs@python components: Documentation messages: 342588 nosy: Aaron Hall, docs@python priority: normal severity: normal status: open title: traceback docstrings should explicitly state return values instead of referring to other functions versions: Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36927> _______________________________________

3 3

[issue18911] minidom does not encode correctly when calling Document.writexml
by Windson Yang May 16, 2019

May 16, 2019

Windson Yang <wiwindson(a)outlook.com> added the comment: I added a PR for like this: .. note:: You should specify the "xmlcharrefreplace" error handler when open a file with specified encoding:: writer = open( filename, "w", encoding="utf-8", errors="xmlcharrefreplace") doc.writexml(writer, "", " ", "utf-8") ---------- nosy: +Windson Yang _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue18911> _______________________________________

1 0

[issue18911] minidom does not encode correctly when calling Document.writexml
by Windson Yang May 16, 2019

May 16, 2019

Change by Windson Yang <wiwindson(a)outlook.com>: ---------- keywords: +patch pull_requests: +13263 stage: needs patch -> patch review _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue18911> _______________________________________

1 0

[issue36932] asyncio-task.rst could use proper deprecated-removed directive
by Matthias Bussonnier May 15, 2019

May 15, 2019

Change by Matthias Bussonnier <bussonniermatthias(a)gmail.com>: ---------- assignee: -> docs@python components: +Documentation nosy: +docs@python versions: +Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36932> _______________________________________

1 0

[issue34648] Confirm the type of traceback.format_list post-3.5
by Nathaniel Manista May 15, 2019

May 15, 2019

New submission from Nathaniel Manista <nathaniel(a)google.com>: So I'm fixing a bug in typeshed's accounting of the traceback module (https://github.com/python/typeshed/pull/2436) and the documented semantics of traceback.format_list don't quite smell to me what I think they might be intended to be: 1) I know it has the name "format_list", but is it really intended to require a list? Why not a sequence, or a collection, or an iterable? I would think it would be fine to pass an iterable to traceback.format_list. Is it fine? 2) What is the desired component type for the aggregate passed to format_list? In 3.4-and-earlier it was Tuple[str, int, str, Optional[str]], and that still works in 3.5-through-3.8, but is that just backwards compatibility or is that something that users of traceback.format_list should feel encouraged to continue passing into the future? Sorry for filing a bug just to ask "huh; really?" but... please confirm? ---------- assignee: docs@python components: Documentation messages: 325175 nosy: Nathaniel Manista, docs@python priority: normal severity: normal status: open title: Confirm the type of traceback.format_list post-3.5 type: behavior versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue34648> _______________________________________

5 8