Mailman 3 April 2021 - docs

[issue24247] Docs: "unittest discover" modifies sys.path
by Irit Katriel 29 Apr '21

29 Apr '21

Irit Katriel <iritkatriel(a)yahoo.com> added the comment: This is alluded to in the "caution" under https://docs.python.org/3/library/unittest.html#test-discovery But the workaround is not explained. ---------- keywords: +easy nosy: +iritkatriel title: "unittest discover" modifies sys.path -> Docs: "unittest discover" modifies sys.path type: -> behavior versions: +Python 3.10, Python 3.11, Python 3.8, Python 3.9 -Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue24247> _______________________________________

1 0

[issue1227748] doc: subprocess: inheritance of std descriptors inconsistent
by Irit Katriel 29 Apr '21

29 Apr '21

Irit Katriel <iritkatriel(a)yahoo.com> added the comment: The patch needs to be converted into a github PR. ---------- keywords: +easy nosy: +iritkatriel title: subprocess: inheritance of std descriptors inconsistent -> doc: subprocess: inheritance of std descriptors inconsistent versions: +Python 3.10, Python 3.11, Python 3.9 -Python 2.7, Python 3.1, Python 3.2 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue1227748> _______________________________________

1 0

[issue23750] Clarify difference between os.system/subprocess.call in section "Replacing os.system()"
by Andreas Sommer 29 Apr '21

29 Apr '21

New submission from Andreas Sommer: Reading over the section "Replacing os.system()" (https://docs.python.org/2/library/subprocess.html#replacing-os-system), one might assume that the return value of os.system and subprocess.call are equivalent. status = os.system("mycmd" + " myarg") # becomes status = subprocess.call("mycmd" + " myarg", shell=True) However, they are not. Example: import sys import os import subprocess print subprocess.call("false") print os.system("false") gives 1 and 256, respectively. Maybe this could be rephrased for clarity, or a hint added. ---------- assignee: docs@python components: Documentation messages: 239028 nosy: Andreas Sommer, docs@python priority: normal severity: normal status: open title: Clarify difference between os.system/subprocess.call in section "Replacing os.system()" type: enhancement _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue23750> _______________________________________

3 3

[issue24475] The docs never define what a pool "task" is
by Zahari Dim 29 Apr '21

29 Apr '21

New submission from Zahari Dim: See: http://stackoverflow.com/questions/30943161/multiprocessing-pool-with-maxta… The documentation never makes clear what a "task" in the context of Pool.map. At best, it says: "This method chops the iterable into a number of chunks which it submits to the process pool as separate tasks. The (approximate) size of these chunks can be specified by setting chunksize to a positive integer." in the map documentation. However it does not say how this chunks are calculated by default, making the maxtasksperchild argument not very useful. The fact that a function evaluated by map is not a "task" should be much clearer in the documentation. Also, in the examples, such as: with multiprocessing.Pool(PROCESSES) as pool: # # Tests # TASKS = [(mul, (i, 7)) for i in range(10)] + \ [(plus, (i, 8)) for i in range(10)] results = [pool.apply_async(calculate, t) for t in TASKS] imap_it = pool.imap(calculatestar, TASKS) imap_unordered_it = pool.imap_unordered(calculatestar, TASKS) TASKS are not actually "tasks" but rather "task groups". ---------- assignee: docs@python components: Documentation messages: 245509 nosy: Zahari.Dim, docs@python priority: normal severity: normal status: open title: The docs never define what a pool "task" is 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/issue24475> _______________________________________

5 4

[issue11975] Fix intersphinx-ing of built-in types (list, int, ...)
by Jonas H. 28 Apr '21

28 Apr '21

New submission from Jonas H. <jonas(a)lophus.org>: Intersphinx-ing of int, list, float, ... should work with ":class:`int`" (list, float, ...). Also, intersphinx-ing list methods, e.g. ":meth:`list.insert`", should work. ---------- assignee: docs@python components: Documentation messages: 134923 nosy: docs@python, jonash priority: normal severity: normal status: open title: Fix intersphinx-ing of built-in types (list, int, ...) _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue11975> _______________________________________

11 50

[issue43959] Improve documentation of PyContextVar C-API
by Stefan Behnel 28 Apr '21

28 Apr '21

New submission from Stefan Behnel <stefan_ml(a)behnel.de>: The documentation of the PyContextVar C-API is unclear in a couple of places. - It's not clear whether PyContextVar_Get() always returns an owned reference also for default values or only if a value was found. - It's not explicit that "optional" actually means "pass an object reference or NULL". - The return value of PyContextVar_Set() is not explained. ---------- assignee: docs@python components: Documentation messages: 392128 nosy: docs@python, scoder priority: normal severity: normal status: open title: Improve documentation of PyContextVar C-API type: enhancement versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue43959> _______________________________________

2 7

[issue20692] Tutorial section 9.4
by Jon Shemitz 28 Apr '21

28 Apr '21

New submission from Jon Shemitz: The tutorial says "Each value is an object, and therefore has a class (also called its type). It is stored as object.__class__." So, I tried >>> 3.__class__ File "<stdin>", line 1 3.__class__ ^ SyntaxError: invalid syntax Yet, "foo".__class__ worked, as did 3j.__class__ and 3.5.__class__. When my son (!) suggested that I try (3).__class__, I did indeed get <type 'int'>, while (3,).__class__ gave <type 'tuple'>. This *looks like* a minor error in the parser, where seeing \d+\. puts it in a state where it expects \d+ and it can't handle \w+ This may be the sort of thing that only a newbie would even think to try, so may not be worth fixing. If so, it may be worth mentioning in the tutorial. ---------- assignee: docs@python components: Documentation, Interpreter Core messages: 211670 nosy: Jon.Shemitz, docs@python priority: normal severity: normal status: open title: Tutorial section 9.4 type: behavior versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue20692> _______________________________________

10 18

[issue26629] Need an ability to build standard DLLs with distutils
by Buraddin Ibn-Karlo 28 Apr '21

28 Apr '21

New submission from Buraddin Ibn-Karlo: I want to make a a dynamic library to run its function with ctypes. Also I want to build the library from sources with distutils (the C++ sources are distributed with my Python code). But alas! Our distutils fails, if the library doesn't have initialization function (something like init_<module_name>). Even if the module does not need any initialization. I did a quick and dirty solution: added a dummy function: void init_<module_name>(){} It somehow works, but I don't think that it is a good idea. Cannot you add the possibility to tell distutils, that this extention module is just a simple DLL, that will be used via ctypes (or somehow else) and it does not need any extra init script? Also, cannot you add an extra section to ctypes documentation? With a description how to build such extensions via distutils? ---------- assignee: docs@python components: Build, Documentation, Extension Modules, Windows, ctypes messages: 262308 nosy: Buraddin Ibn-Karlo, docs@python, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Need an ability to build standard DLLs with distutils type: enhancement versions: Python 2.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue26629> _______________________________________

3 3

[issue43956] C-API: Incorrect default value for Py_SetProgramName
by Jouke Witteveen 28 Apr '21

28 Apr '21

New submission from Jouke Witteveen <j.witteveen(a)gmail.com>: The default program name is hardcoded in Python/initconfig.c:config_init_program_name. It is "python" on Windows, and "python3" elsewhere. The documentation currently suggests that it is "python" everywhere. Additionally, the documentation currently says: > The argument should point to a zero-terminated wide character string in static storage whose contents will not change for the duration of the program’s execution. The code, however, duplicates the string, so I am not sure this is true. ---------- assignee: docs@python components: Documentation messages: 392113 nosy: docs@python, joukewitteveen priority: normal pull_requests: 24356 severity: normal status: open title: C-API: Incorrect default value for Py_SetProgramName versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue43956> _______________________________________

1 0

[issue41661] os.path.relpath does not document ValueError on Windows with different drives
by Andy Maier 27 Apr '21

27 Apr '21

New submission from Andy Maier <andreas.r.maier(a)gmx.de>: I found that os.path.relpath() on Windows raises ValueError when the path and the start path are on different drives. This is to be expected, as there is no single root on Windows. On Python 3.7, the behavior is: >>> os.path.relpath('c:/abc', 'a:/') Traceback (most recent call last): File "<stdin>", line 1, in <module> File "...\Python\Python37\lib\ntpath.py", line 564, in relpath path_drive, start_drive)) ValueError: path is on mount 'c:', start on mount 'a:' The issue is that this ValueError and the reasons for it are not mentioned at all in the documentation for os.path.relpath(). Other os.path functions do document specific behaviors for different drives on Windows, for example os.path.commonpath(), so there is a precedence for documenting this. Also, it should be normal to document the possible exceptions that can be raised. I did read https://bugs.python.org/issue7195 from 2009 where the original issue discussed also lead to a request to update the documentation of os.path.relpath() to show the ValueError for this case, but that angle of the issue ended up being ignored back then, unfortunately. My suggestion is to add something like the following sentence the documentation: "On Windows, ValueError is raised when path and start are on different drives." ---------- assignee: docs@python components: Documentation messages: 376057 nosy: andymaier, docs@python priority: normal severity: normal status: open title: os.path.relpath does not document ValueError on Windows with different drives versions: Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue41661> _______________________________________

7 9