Mailman 3 April 2018 - docs

[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

[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

[issue20582] socket.getnameinfo() does not document flags
by Roy Smith Nov. 20, 2020

Nov. 20, 2020

New submission from Roy Smith: http://docs.python.org/2/library/socket.html The description for getnameinfo() says, "... Depending on the settings of flags, the result can contain a fully-qualified domain name or numeric address representation in host.", but does not say what to pass for flags to get those behaviors. ---------- assignee: docs@python components: Documentation messages: 210838 nosy: docs@python, roysmith priority: normal severity: normal status: open title: socket.getnameinfo() does not document flags versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue20582> _______________________________________

9 12

[issue17854] symmetric difference operation applicable to more than two sets
by Amit Saha Nov. 18, 2020

Nov. 18, 2020

New submission from Amit Saha: The description of the symmetric difference operation implies that it cannot be applied to more than two sets (http://docs.python.org/3/library/stdtypes.html#set.symmetric_difference). However, this is certainly possible: >>> s={1,2} >>> t={2,3} >>> u={3,4} >>> s^t^u {1, 4} >>> s.symmetric_difference(t).symmetric_difference(u) {1, 4} I am not sure how much of a "semantic" sense that makes, given that symmetric difference is by definition for two sets. (http://en.wikipedia.org/wiki/Symmetric_difference). So, either the operator should be fixed to allow only two sets or the description be updated. ---------- assignee: docs@python components: Documentation messages: 187899 nosy: Amit.Saha, docs@python priority: normal severity: normal status: open title: symmetric difference operation applicable to more than two sets type: behavior versions: Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17854> _______________________________________

6 8