Mailman 3 March 2019 - docs

[issue33300] Bad usage example in id() DocString
by Glen Neff Oct. 31, 2020

Oct. 31, 2020

New submission from Glen Neff <gneff(a)trioptimum.com>: The DocString for id() in 3.5.x & 3.6.x seems to have an incorrect usage example, specifically ``id(obj, /)``. This is present in 3.5.x & 3.6.x. It does not appear to be present in 2.7.x or 3.4.x.: Python 3.6.4 (v3.6.4:d48eceb, Dec 19 2017, 06:54:40) [MSC v.1900 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> help(id) Help on built-in function id in module builtins: id(obj, /) Return the identity of an object. This is guaranteed to be unique among simultaneously existing objects. (CPython uses the object's memory address.) >>> ---------- assignee: docs@python components: Documentation messages: 315410 nosy: docs@python, gneff priority: normal severity: normal status: open title: Bad usage example in id() DocString versions: Python 3.5, Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue33300> _______________________________________

3 3

[issue21078] multiprocessing.managers.BaseManager.__init__'s "serializer" argument is not documented
by Yuriy Taraday Oct. 30, 2020

Oct. 30, 2020

New submission from Yuriy Taraday: We're going to use BaseManager for simple secure local RPC and for the "secure" part we can't use pickle, so we have to use "serializer" argument to switch to xmlrpclib. We need to be sure that argument won't go away so we need it to be documented and supported on future versions. ---------- assignee: docs@python components: Documentation messages: 214967 nosy: docs@python, yorik.sar priority: normal severity: normal status: open title: multiprocessing.managers.BaseManager.__init__'s "serializer" argument is not documented versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue21078> _______________________________________

5 7

[issue10936] Simple CSS fix for left margin at docs.python.org
by Christopher Dunn Oct. 30, 2020

Oct. 30, 2020

New submission from Christopher Dunn <cdunn2001(a)gmail.com>: This is an easy one. When I zoom my browser in (with Ctrl+ or Apple+) the left-side navigation margin gets bigger and bigger, pushing the useful text off the screen. That has bothered me (and anyone else with 40+ year old eyes) ever since the switch to the newest doc format with Sphinx. There is no fix that will satisfy everyone. People with perfect vision might like to zoom out (with Ctrl- or Apple-), since the margin currently gets smaller and smaller. But we need a compromise. The relevant CSS, in default.css, is this: div.bodywrapper { margin: 0 0 0 230px; } If instead it were something like this: div.bodywrapper { margin: 0 0 0 10%; } then at least the navigation margin would stay the same size always. If you really want it to grow and shrink, then you need some sort of javascript control of its position. ---------- assignee: docs@python components: Documentation messages: 126477 nosy: cdunn2001, docs@python priority: normal severity: normal status: open title: Simple CSS fix for left margin at docs.python.org type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue10936> _______________________________________

8 16

[issue15029] Update Defining New Types chapter according to PEP 253
by Mateusz Loskot Oct. 27, 2020

Oct. 27, 2020

New submission from Mateusz Loskot <mateusz(a)loskot.net>: The chapter '2. Defining New Types" in the Python 3.2 documentation [1] does not cover all important elements, especially in the subsection 2.1.4. Subclassing other types. The accepted PEP 253 [2] provides much more detailed and thorough explanation for Python C API users willing to define and subclass new types, than the official manual. I'd like to suggest update of the manual with information enclosed in the PEP 253. In fact, the PEP's sections like * Preparing a type for subtyping * Creating a subtype of a built-in type in C could be copied with little editing, IMHO. The PEP 253 really seems to be a must-read document for Python C API users. [1] http://docs.python.org/release/3.2.2/extending/newtypes.html [2] http://www.python.org/dev/peps/pep-0253/ ---------- assignee: docs@python components: Documentation messages: 162480 nosy: docs@python, mloskot priority: normal severity: normal status: open title: Update Defining New Types chapter according to PEP 253 type: enhancement versions: Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15029> _______________________________________

2 2

[issue32122] Improve -x option documentation
by Serhiy Storchaka Oct. 26, 2020

Oct. 26, 2020

New submission from Serhiy Storchaka <storchaka+cpython(a)gmail.com>: The documentation of the -x option is virtually not existing. The current short line of the description was enough to me for understanding what is the purpose of this option and how it can be used (I didn't use Windows for more than 10 years). But I was surprised not founding more detailed information about this feature in the documentation. Definitely it should be better documented. Most of users will have no ideas about this feature. The purpose of this option is turning Python scripts into Windows batch files which can be ran as other executables. Similarly as adding she-bang and setting the executable bit allows to run them on Unix. The extension of the Python script should be changed to ".bat", and the following line should be added at the start of the script: @path\to\python -x %0 %* & exit /b Or @py -3 -x %0 %* & exit /b Unlike a she-bang line which is a Python comment, this line is not valid Python syntax, and the -x option is used for skipping it. ---------- assignee: docs@python components: Documentation, Windows messages: 306878 nosy: docs@python, paul.moore, serhiy.storchaka, steve.dower, tim.golden, zach.ware priority: normal severity: normal stage: needs patch status: open title: Improve -x option documentation type: enhancement versions: Python 2.7, Python 3.6, Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue32122> _______________________________________

4 5

[issue21510] fma documentation should provide better example.
by Jayanth Koushik Oct. 26, 2020

Oct. 26, 2020

New submission from Jayanth Koushik: The documentation for decimal.fma provides an example which fails to illustrate the most important feature of the function i.e. single rounding. In fact: Decimal(2).fma(3, 5) == Decimal(2)*3 + 5 An example such as this would make it much more clear: >>> getcontext().prec = 2 >>> getcontext().rounding = ROUND_DOWN >>> Decimal('1.5')*Decimal('1.5') + Decimal('1.05') Decimal('3.2') >>> Decimal('1.5').fma(Decimal('1.5'), Decimal('1.05')) Decimal('3.3') ---------- assignee: docs@python components: Documentation messages: 218592 nosy: docs@python, jayanthkoushik priority: normal severity: normal status: open title: fma documentation should provide better example. type: enhancement versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue21510> _______________________________________

6 7

[issue26954] Add Guido's rejection notice to the "with" FAQ
by Steven D'Aprano Oct. 26, 2020

Oct. 26, 2020

New submission from Steven D'Aprano: The FAQs include a discussion of the rejected Pascal "with" statement (different from the Python `with`). From time to time people propose variants of it, such as using a leading dot to make it unambiguous. Guido has just firmly rejected the latest such proposal. The FAQ should be updated to make it clear that even with a leading dot the proposal is dead, with a link to Guido's pronouncement. https://mail.python.org/pipermail/python-ideas/2016-May/040070.html ---------- assignee: docs@python components: Documentation messages: 264832 nosy: docs@python, steven.daprano priority: normal severity: normal status: open title: Add Guido's rejection notice to the "with" FAQ versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue26954> _______________________________________

2 1

[issue15339] document the threading "facts of life" in Python
by Chris Jerdonek Oct. 26, 2020

Oct. 26, 2020

New submission from Chris Jerdonek <chris.jerdonek(a)gmail.com>: I think it would be helpful if the Python documentation included certain high-level information about multi-threading in Python. At minimum, I think it would help for the documentation to provide a definition that can be linked to of what it means when some part of the Python documentation says something is "thread-safe". In particular, such a definition could clarify that this is different from being atomic. This might best be addressed by an entry in the glossary for the term "thread-safe". Other documentation possibilities include stating what guarantees one should or should not expect regarding thread-safety, both within and across implementations, and providing centralized guidance on how to approach multi-threaded programming in Python. A HOWTO is one possibility for addressing these other possibilities. This issue stems from the discussion in issue 15329, which is more specific. ---------- assignee: docs@python components: Documentation messages: 165336 nosy: cjerdonek, docs@python priority: normal severity: normal status: open title: document the threading "facts of life" in Python _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15339> _______________________________________

8 8

[issue12832] The documentation for the print function should explain/point to how to control the sys.stdout encoding
by R. David Murray Oct. 25, 2020

Oct. 25, 2020

New submission from R. David Murray <rdmurray(a)bitdance.com>: A common problem encountered when using python3 is writing non-ascii to stdout. This will work fine if stdout is a terminal and the terminal encoding handles the characters, but will fail if stdout is later redirected to a pipe. The docs for sys.stdout and for print should contain or point to an explanation of why, and how to solve the problem (ie: how to set the encoding for sys.stdout/sys.stderr). Note that IMO it makes more sense for sys.stdout to default to the LOCALE encoding, but that should be a separate issue. ---------- assignee: docs@python components: Documentation messages: 142880 nosy: docs@python, r.david.murray priority: normal severity: normal status: open title: The documentation for the print function should explain/point to how to control the sys.stdout encoding versions: Python 2.7, Python 3.2, Python 3.3 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue12832> _______________________________________

4 7

[issue29981] Update Index set, dict, and generator 'comprehensions'
by Terry J. Reedy Oct. 24, 2020

Oct. 24, 2020

New submission from Terry J. Reedy: The index currently has comprehensions *list* with *list* linked to 6.2.5 List displays. I suggest: 1. Link *comprehensions* to 6.2.4. Displays for lists, sets and dictionaries 2. Add subentries *set*, *dict*, and *generator* linked to 2a. 6.2.6. Set displays 2b. 6.2.7. Dictionary displays 2c. 6.2.8. Generator expressions We don't *call* generator expressions 'generator comprehensions', but that is what they are syntactically and one looking for 'comprehensions' should be able to find them there. There is already *list* ... *comprehensions* ... *list comprehensions* with 'list' and 'list comprehensions' linked to glossary entries, while 'list, comprehensions' links to the same section as 'comprehensions, list'. 3. Add 'set/dictionary, comprehensions' sub-entries linked like 'list, com 4. Add Glossary entries and links like 'list comprehensions' ---------- assignee: docs@python components: Documentation keywords: easy messages: 291129 nosy: docs@python, terry.reedy priority: normal severity: normal stage: needs patch status: open title: Update Index set, dict, and generator 'comprehensions' type: behavior versions: Python 3.6, Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue29981> _______________________________________

8 16