Mailman 3 July 2018 - docs

[issue23802] patch: __deepcopy__ memo dict argument usage
by Daniel Shahaf Aug. 18, 2020

Aug. 18, 2020

New submission from Daniel Shahaf: In the 'copy' module documentation, it wasn't fully clear to me how __deepcopy__ implementations should treat the memo dict argument. The attached patch clarifies that __deepcopy__ implementations should treat the memo dict argument as an opaque type. ---------- assignee: docs@python components: Documentation files: opaque.diff keywords: patch messages: 239473 nosy: danielsh, docs@python priority: normal severity: normal status: open title: patch: __deepcopy__ memo dict argument usage type: enhancement Added file: http://bugs.python.org/file38723/opaque.diff _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23802> _______________________________________

4 6

[issue30757] pyinstaller can be added to docs, py2exe ref can be updated
by Denis Akhiyarov Aug. 17, 2020

Aug. 17, 2020

New submission from Denis Akhiyarov: https://github.com/python/cpython/pull/1158 It is not clear why this FAQ item is written in addition to this document: https://github.com/python/cpython/blob/master/Doc/faq/windows.rst#how-do-i-… https://github.com/python/cpython/blob/master/Doc/faq/programming.rst#how-c… ---------- assignee: docs@python components: Documentation messages: 296844 nosy: denfromufa, docs@python priority: normal severity: normal status: open title: pyinstaller can be added to docs, py2exe ref can be updated type: enhancement versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue30757> _______________________________________

4 4

[issue28681] About function renaming in the tutorial
by Xue Fuqiao July 6, 2020

July 6, 2020

New submission from Xue Fuqiao: In https://hg.python.org/cpython/file/6fbb7c9d77c6/Doc/tutorial/controlflow.rs… : A function definition introduces the function name in the current symbol table. The value of the function name has a type that is recognized by the interpreter as a user-defined function. This value can be assigned to another name which can then also be used as a function. This serves as a general renaming mechanism Maybe "aliasing" is a better term than "renaming" here, since the original function name can still be used after the "renaming". ---------- assignee: docs@python components: Documentation files: renaming.patch keywords: patch messages: 280683 nosy: docs@python, xfq priority: normal severity: normal status: open title: About function renaming in the tutorial type: enhancement versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45468/renaming.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue28681> _______________________________________

9 16

[issue21333] Document recommended exception for objects that shouldn't be pickled
by Stefan Schwarzer July 5, 2020

July 5, 2020

New submission from Stefan Schwarzer: I recently was confused whether to raise a `PicklingError` or `TypeError` in `__getstate__` if objects of my class can't and shouldn't be pickled. [1] Terry Reedy advised I should use `TypeError`. [2] I wonder if the `pickle` module documention should explicitly recommend using `TypeError` if a class wants to say that its objects can't be pickled. What do you think? [1] https://mail.python.org/pipermail/python-list/2014-April/670987.html [2] https://mail.python.org/pipermail/python-list/2014-April/671002.html ---------- assignee: docs@python components: Documentation messages: 217054 nosy: docs@python, sschwarzer priority: normal severity: normal status: open title: Document recommended exception for objects that shouldn't be pickled type: enhancement versions: Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue21333> _______________________________________

5 4

[issue33864] collections.abc.ByteString does not register memoryview
by Jason Fried July 4, 2020

July 4, 2020

New submission from Jason Fried <me(a)jasonfried.info>: Looking at the typing Module docs in the section for ByteString This type represents the types bytes, bytearray, and memoryview. But collections.abc.ByteString does not have memoryview registered. Is it because memoryview doesn't support .index()? ---------- assignee: docs@python components: Documentation messages: 319557 nosy: docs@python, fried, lukasz.langa priority: normal severity: normal status: open title: collections.abc.ByteString does not register memoryview type: behavior versions: Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue33864> _______________________________________

6 9

[issue17805] No such class: multiprocessing.pool.AsyncResult
by Takafumi Arakaki July 3, 2020

July 3, 2020

New submission from Takafumi Arakaki: Document mentions AsyncResult but there is no such class. http://docs.python.org/2/library/multiprocessing.html#multiprocessing.pool.… You can check it by simply running: python -c 'from multiprocessing.pool import AsyncResult' I think it means ApplyResult so I made a patch (attached). Note that there managers.py also uses name 'AsyncResult': % hg grep AsyncResult Doc/library/multiprocessing.rst:83232:.. class:: AsyncResult Lib/multiprocessing/managers.py:81039: 'apply_async': 'AsyncResult', Lib/multiprocessing/managers.py:81039: 'map_async': 'AsyncResult', Lib/multiprocessing/managers.py:81039: 'starmap_async': 'AsyncResult', Lib/multiprocessing/managers.py:81039:SyncManager.register('AsyncResult', create_method=False) Probably renaming them would be better? ---------- assignee: docs@python components: Documentation files: ApplyResult.patch keywords: patch messages: 187466 nosy: docs@python, tkf priority: normal severity: normal status: open title: No such class: multiprocessing.pool.AsyncResult versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file29954/ApplyResult.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue17805> _______________________________________

6 8

[issue23427] Python should expose command when invoked with -c
by Jan-Philip Gehrcke June 29, 2020

June 29, 2020

New submission from Jan-Philip Gehrcke: When Python is invoked with the `-c command` switch, the command string does not get exposed in sys.argv: $ python -c "import sys; print(sys.argv)" ['-c'] $ python -c "import sys; print(sys.argv)" arg1 ['-c', 'arg1'] The command string does not get exposed anywhere, AFAIK, so it is inaccessible from within Python programs. There might be application scenarios in which it is useful to access the command string, such as for debugging purposes. One scenario is when a Python session should be able to "re-spawn" itself in a subprocess (I came across this question on StackOverflow: http://stackoverflow.com/q/28412903/145400) I propose to make the command string accessible. If you agree that it might make sense, the question is *how/where* to expose it. One possible way is to retain it in sys.argv, as in this example: $ python -c "import sys; print(sys.argv)" "arg1" ['-c', 'import sys; print(sys.argv)', 'arg1'] The current sys.argv docs say > If the command was executed using the -c command line option to > the interpreter, argv[0] is set to the string '-c'. This sentence could then be adjusted to "[...], argv[0] is set to the string '-c', and argv[1] contains the command." This method breaks existing applications that are started with the -c method and that consume command line arguments in a sys.argv[1:] fashion. The tests in Lib/test/test_cmd_line.py all pass, however. A second method would be to change sys.argv[0] from '-c' to '-c command'. This would break existing applications that check for sys.argv[0] == 'c'. A third method would be to leave sys.argv as it is, and expose the command with a new attribute in the sys module. I have attached a patch for variant 1 (passes all tests in Lib/test/test_cmd_line.py), to demonstrate which code is affected: the translation from the "real" argv to sys' argv is triggered in Modules/main.c. The patch does not change behavior of '-m' (it's funny, however, that the current version of main.c at first replaces the module string with '-m', whereas the runpy module later on replaces '-m' with the path to the module file anyway.). As a side node, I figure that the sys.argv documentation should be adjusted to properly reflect the -m behavior, which is: $ ./python -m testmodule foo testmodule sys.argv: ['/data/local/pythondev/pythontip/cpython/testmodule.py', 'foo'] Let me hear your comments, and I am willing to work on code and doc patches, thanks! ---------- assignee: docs@python components: Documentation, Interpreter Core files: sys_argv_cmd.patch keywords: patch messages: 235633 nosy: docs@python, georg.brandl, haypo, jgehrcke, pitrou priority: normal severity: normal status: open title: Python should expose command when invoked with -c type: enhancement versions: Python 3.5, Python 3.6 Added file: http://bugs.python.org/file38065/sys_argv_cmd.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23427> _______________________________________

7 20

[issue33553] possible documentation improvement proposal for multiprocessing
by Derek Kim June 28, 2020

June 28, 2020

New submission from Derek Kim <bluewhale8202(a)gmail.com>: >>> from multiprocessing import Pool >>> p = Pool(5) >>> def f(x): ... return x*x ... >>> p.map(f, [1,2,3]) This example in the document is confusing because this is already wrong code when run with fork method even if you run it as a script. With fork start method, f should be defined before p is created. Also, just advising that one shouldn't use interactive shell and should run multiprocessing code in if __name__ == '__main__' is not informative becuase those conditions are generally no problem with fork method. Can I try improving the documentation? ---------- assignee: docs@python components: Documentation messages: 316892 nosy: Derek Kim, docs@python priority: normal severity: normal status: open title: possible documentation improvement proposal for multiprocessing versions: Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue33553> _______________________________________

3 4

[issue31082] reduce takes iterable, not just sequence
by Stefan Pochmann June 28, 2020

June 28, 2020

New submission from Stefan Pochmann: functools.reduce has a parameter called "iterable" and it only needs to be an iterable, not a sequence. The paragraph documenting it says "sequence" instead of "iterable" six times: https://docs.python.org/3/library/functools.html#functools.reduce The help shown by executing "help(functools.reduce)" in Python additionally actually names the parameter "sequence" in the signature. ---------- assignee: docs@python components: Documentation messages: 299520 nosy: Stefan Pochmann, docs@python priority: normal severity: normal status: open title: reduce takes iterable, not just sequence type: enhancement versions: Python 3.6, Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue31082> _______________________________________

6 7

[issue30951] Documentation error in inspect module
by Alex Vig June 25, 2020

June 25, 2020

New submission from Alex Vig: The documentation for co_names in the inspect module is: "tuple of names of local variables" Local variable names are however in co_varnames while co_names contains global variable names. This description should read: "tuple of names of global variables" Relevant StackOverflow post here: https://stackoverflow.com/q/45147260/1953800 ---------- assignee: docs@python components: Documentation messages: 298545 nosy: Alex Vig, docs@python priority: normal severity: normal status: open title: Documentation error in inspect module versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue30951> _______________________________________

8 10