Mailman 3 February 2020 - docs

[issue32830] tkinter documentation suggests "from tkinter import *", contradicting PEP8
by ChrisRands Dec. 1, 2020

Dec. 1, 2020

New submission from ChrisRands <chrisrands0(a)gmail.com>: Issue arose from this SO post: https://stackoverflow.com/questions/48746351/documentation-is-contradicting… The tkinter documentation suggests: from tkinter import * https://docs.python.org/3/library/tkinter.html But this obviously contradicts PEP8: "Wildcard imports (from <module> import *) should be avoided" https://www.python.org/dev/peps/pep-0008/#imports Is tkinter a valid exception or is this a documentation bug? The commit of this line to the documentation is >10 years old (at least Python 2.4 I think): https://github.com/python/cpython/commit/116aa62bf54a39697e25f21d6cf6799f7f… ---------- assignee: docs@python components: Documentation messages: 312045 nosy: ChrisRands, docs@python priority: normal severity: normal status: open title: tkinter documentation suggests "from tkinter import *", contradicting PEP8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue32830> _______________________________________

4 6

[issue15104] abusive language in __name__ description
by anatoly techtonik Dec. 1, 2020

Dec. 1, 2020

New submission from anatoly techtonik <techtonik(a)gmail.com>: http://docs.python.org/library/__main__.html "It is this environment in which the idiomatic “conditional script” stanza causes a script to run" ?!? ---------- assignee: docs@python components: Documentation messages: 163140 nosy: docs@python, techtonik priority: normal severity: normal status: open title: abusive language in __name__ description _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15104> _______________________________________

12 28

[issue21195] None float format: incomplete documentation
by Eric O. LEBIGOT Dec. 1, 2020

Dec. 1, 2020

New submission from Eric O. LEBIGOT: The documentation for a None (empty) format for floats indicates that it is equivalent to the g format. This does not appear to be correct (http://stackoverflow.com/questions/16525924/precise-definition-of-float-str…). The Python 3.4 documentation (https://docs.python.org/3.4/library/string.html#format-specification-mini-l…) seems to be much closer to what Python 2.7 does. It would be useful to have a more correct documentation for the effect of a None format for floats in Python 2.7 (maybe by copying the Python 3.4 documentation if it applies). ---------- assignee: docs@python components: Documentation messages: 215871 nosy: docs@python, lebigot priority: normal severity: normal status: open title: None float format: incomplete documentation type: enhancement versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue21195> _______________________________________

4 6

[issue13341] Incorrect documentation for "u" PyArg_Parse format unit
by Ilya Novoselov Nov. 30, 2020

Nov. 30, 2020

New submission from Ilya Novoselov <ilya.novoselov(a)gmail.com>: Documentation states that u format unit returns "buffer of 16-bit Unicode (UTF-16) data" while it returns pointer to internal buffer of unicode data, which is either UCS-16 or UCS-32 http://docs.python.org/c-api/arg.html ---------- assignee: docs@python components: Documentation, Unicode messages: 147002 nosy: Ilya.Novoselov, docs@python, ezio.melotti priority: normal severity: normal status: open title: Incorrect documentation for "u" PyArg_Parse format unit type: behavior versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue13341> _______________________________________

7 9

[issue31189] README.rst: installing multiple versions: typo
by Дилян Палаузов Nov. 26, 2020

Nov. 26, 2020

New submission from Дилян Палаузов: It speaks about pythonX.Y but means python3.${subversion} diff --git a/README.rst b/README.rst --- a/README.rst +++ b/README.rst @@ -190,7 +190,7 @@ script) you must take care that your primary python executable is not overwritten by the installation of a different version. All files and directories installed using ``make altinstall`` contain the major and minor version and can thus live side-by-side. ``make install`` also creates -``${prefix}/bin/python3`` which refers to ``${prefix}/bin/pythonX.Y``. If you +``${prefix}/bin/python3`` which refers to ``${prefix}/bin/python3.X``. If you intend to install multiple versions using the same prefix you must decide which version (if any) is your "primary" version. Install that version using ``make install``. Install all other versions using ``make altinstall``. ---------- assignee: docs@python components: Documentation messages: 300205 nosy: dilyan.palauzov, docs@python priority: normal severity: normal status: open title: README.rst: installing multiple versions: typo versions: Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue31189> _______________________________________

2 1

[issue27259] Possible missing deprecation warnings?
by Mark Summerfield Nov. 26, 2020

Nov. 26, 2020

New submission from Mark Summerfield: In the docs for the array module: https://docs.python.org/dev/library/array.html#module-array Note 1 in the table of type codes says that the 'u' type is deprecated and will go in Python 4.0. Since the array.fromunicode() and array.tounicode() methods depend on type code 'u' shouldn't they also be marked as deprecated? If people use the 'u' type code maybe it would be helpful to provide an example of how to store unicode chars in an array.array? (Presumably they'd use type code 'L' and use ord() and chr()?) ---------- assignee: docs@python components: Documentation messages: 267738 nosy: docs@python, mark priority: normal severity: normal status: open title: Possible missing deprecation warnings? type: enhancement versions: Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue27259> _______________________________________

2 1

[issue27839] "Python [...] calls sys.displayhook() on unhandled exceptions"
by Jakub Wilk Nov. 25, 2020

Nov. 25, 2020

New submission from Jakub Wilk: <https://docs.python.org/3/library/asyncio-dev.html#detect-exceptions-never-…> reads: "Python usually calls sys.displayhook() on unhandled exceptions. If Future.set_exception() is called, but the exception is never consumed, sys.displayhook() is not called." I believe this should be s/displayhook/excepthook/g. ---------- assignee: docs@python components: Documentation messages: 273446 nosy: docs@python, jwilk priority: normal severity: normal status: open title: "Python [...] calls sys.displayhook() on unhandled exceptions" _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue27839> _______________________________________

2 1

[issue34394] Descriptors HowTo doesn't mention __set_name__
by Semyon Nov. 24, 2020

Nov. 24, 2020

New submission from Semyon <simeon+bpo(a)maryasin.name>: There is a great HowTo document for descriptors https://github.com/python/cpython/blob/master/Doc/howto/descriptor.rst But it doesn't even mention the __set_name__ method which was added in py3. And it lists the descriptor protocol without that method as if it is the full protocol. The only way to know about that method is to go to the link for any other method and then you'll see that there is a __set_name__. I think the guide sholud be updated to include at least information about existence of __set_name__. ---------- assignee: docs@python components: Documentation messages: 323479 nosy: MarSoft, docs@python priority: normal severity: normal status: open title: Descriptors HowTo doesn't mention __set_name__ versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue34394> _______________________________________

3 6

[issue17576] PyNumber_Index() is not int-subclass friendly
by Barry A. Warsaw Nov. 23, 2020

Nov. 23, 2020

New submission from Barry A. Warsaw: operator.index() is just a thin wrapper around PyNumber_Index(). The documentation for operator.index() claims that it is equivalent to calling obj.__index__() but for subclasses of int, this is not true. In fact, PyNumber_Index() first does (e.g. in Python 3.3) a PyLong_Check() and if that succeeds, the original object is returned *without* doing the moral equivalent in C of calling obj.__index__(). An example: class myint(int): def __index__(self): return int(self) + 1 >>> x = myint(7) >>> x.__index__() 8 >>> from operator import index >>> index(x) 7 The C API documents PyNumber_Index() as: "Returns the o converted to a Python int on success or NULL with a TypeError exception raised on failure." Because this has been the behavior of PyNumber_Index() since at least 2.7 (I didn't check farther back), this probably cannot be classified as a bug deserving to be fixed in the code for older Pythons. It might be worth fixing for Python 3.4, i.e. by moving the index check before the type check. In the meantime, this is probably a documentation bug. The C API implies, but should be clearer that if o is an int subtype (int and long in Python 2), it is returned unchanged. The operator.index() documentation should be amended to describe this behavior for int/long subclasses. A different alternative would be to leave PyNumber_Index() unchanged, but with the doco fix, and to augment operator.index() to do the PyIndex_Check() first, before calling PyNumber_Index(). That's a little more redundant, but would provide the documented behavior without changing the C API. ---------- assignee: docs@python components: Documentation messages: 185522 nosy: barry, docs@python priority: normal severity: normal status: open title: PyNumber_Index() is not int-subclass friendly type: behavior versions: 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/issue17576> _______________________________________

14 63

[issue33167] RFC Documentation Updates to urllib.parse.rst
by Matt Eaton Nov. 22, 2020

Nov. 22, 2020

New submission from Matt Eaton <agnosticdev(a)gmail.com>: A recent patch that I worked on resulted in an agreement that there could be a use case for a new URL API to be added to urllib.parse. See: https://bugs.python.org/issue33034 In my research to develop this new API I have been looking at the documentation for urllib.parse -https://docs.python.org/3/library/urllib.parse.html and thought that the descriptions for the RFC documents could use an update to better reflect the meaning of the document. ---------- assignee: docs@python components: Documentation messages: 314584 nosy: agnosticdev, docs@python priority: normal severity: normal status: open title: RFC Documentation Updates to urllib.parse.rst versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue33167> _______________________________________

3 4