Mailman 3 April 2021 - docs

[issue41277] documentation: os.setxattr() errno EEXIST and ENODATA
by Roundup Robot April 30, 2021

April 30, 2021

Change by Roundup Robot <devnull(a)psf.upfronthosting.co.za>: ---------- nosy: +python-dev nosy_count: 3.0 -> 4.0 pull_requests: +24432 pull_request: https://github.com/python/cpython/pull/25742 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue41277> _______________________________________

1 0

[issue43954] Possible missing word on unittest doc
by Julien Palard April 30, 2021

April 30, 2021

New submission from Julien Palard <julien+python(a)palard.fr>: In https://docs.python.org/3/library/unittest.html I see: > Note that you need to the top level directory too. Trying to guess, the missing word may be "specify": > Changed in version 3.4: Test discovery supports namespace packages for start directory. Note that you need to specify the top level directory too. (e.g. python -m unittest discover -s root/namespace -t root). Am I right? ---------- assignee: docs@python components: Documentation messages: 392060 nosy: docs@python, mdk, methane priority: normal severity: normal status: open title: Possible missing word on unittest doc versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue43954> _______________________________________

6 11

[issue24247] Docs: "unittest discover" modifies sys.path
by Rahul Kumaresan April 30, 2021

April 30, 2021

Change by Rahul Kumaresan <kayrahul(a)gmail.com>: ---------- nosy: +rahul-kumi _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue24247> _______________________________________

1 0

Documentation bug
by James Budarz April 29, 2021

April 29, 2021

Hi, I see a bug on docs.python.org/3/library/typing. Under typing.NoReturn it says both "New in version 3.5.4" and "New in version 3.6.2" I don't see how both of these can be true, unless it means "New for 3.5 in version 3.5.4 and new for 3.6 in 3.6.2" Thanks!

2 1

[issue43614] Search is not beginner friendly
by Anthony Flury April 29, 2021

April 29, 2021

New submission from Anthony Flury <anthony.flury(a)btinternet.com>: A commonly asked question on Quora is 'What do *args and **kwargs' mean ? While it is relatively easy for community to answer these questions the search tool on the standard documentation doesn't make it easy. I understand that 'args' and 'kwargs' are both naming conventions, they are very common across the documentation, but searching on '*args' or '**kwargs' doesn't actually find anything useful - it certainly doesn't place 'https://docs.python.org/3/tutorial/controlflow.html#arbitrary-argument-lists' at or close to the top of the list. It is my view that the documentation should be beginner friendly, but in this case (and many other I guess) you have to know what to search for to find something useful. I note that even common phrases in Computing (such as 'variable arguments' or 'variable parameters') don't find anything useful. The term 'variadic' does find the relevant page, but the link displayed in the search results lands on the page (but not the relevant section) - and many beginners wont search for 'variadic'. The index and search need to be improved to help beginners - specifically in this case * Search Index should include common conventional names (such as args, kwargs) * Search Index should include common computing terms ('variable arguments' for example - even if the documentation doesn't actually use that terminology). * Search should link to the relevant section (and not just the page). ---------- assignee: docs@python components: Documentation messages: 389442 nosy: anthony-flury, docs@python priority: normal severity: normal status: open title: Search is not beginner friendly versions: Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue43614> _______________________________________

5 5

[issue32824] Docs: Using Python on a Macintosh has bad info per Apple site
by Frank Griswold April 29, 2021

April 29, 2021

New submission from Frank Griswold <py.griswolf(a)spamgourmet.com>: This chunk of docs has bad info in both Python2 and Python3 docs: 4.1.3. Configuration Python on OS X honors all standard Unix environment variables such as PYTHONPATH, but setting these variables for programs started from the Finder is non-standard as the Finder does not read your .profile or .cshrc at startup. You need to create a file ~/.MacOSX/environment.plist. See Apple’s Technical Document QA1067 for details. If you search for QA1067, you are informed that the document is legacy and unsupported, with a suggestion for where to look now. That suggested link leads to a 404. Searching the apple site, I find that at least some thoughtful developers think that configuring the environment isn't even possible, generally; and isn't considered good form even if so. Here: https://forums.developer.apple.com/message/217422 I have no problem setting things for my terminal, as a longtime (unix) user, but for others, this section probably needs a complete examination with an eye toward making it current. quite possibly by reorganizing it. ---------- assignee: docs@python components: Documentation messages: 312023 nosy: docs@python, griswolf priority: normal severity: normal status: open title: Docs: Using Python on a Macintosh has bad info per Apple site type: enhancement _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue32824> _______________________________________

7 10

[issue43774] [Doc] Document configure options in the Python documentation
by STINNER Victor April 29, 2021

April 29, 2021

New submission from STINNER Victor <vstinner(a)python.org>: Attached PR documents configure, compiler and linker options to build Python. ---------- assignee: docs@python components: Documentation messages: 390536 nosy: docs@python, vstinner priority: normal severity: normal status: open title: [Doc] Document configure options in the Python documentation versions: Python 3.10 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue43774> _______________________________________

5 23

[issue1227748] doc: subprocess: inheritance of std descriptors inconsistent
by STINNER Victor April 29, 2021

April 29, 2021

Change by STINNER Victor <vstinner(a)python.org>: ---------- nosy: -vstinner _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue1227748> _______________________________________

1 0

[issue1227748] doc: subprocess: inheritance of std descriptors inconsistent
by Eryk Sun April 29, 2021

April 29, 2021

Eryk Sun <eryksun(a)gmail.com> added the comment: > If one calls Popen with stdin = stdout = stderr = None, > the caller's std descriptors are inherited on *x, but > not on Windows In the default case, CreateProcessW() is called with bInheritHandles as false and without explicitly setting the standard-handle values. Also, creationflags is 0 in the default case, not CREATE_NEW_CONSOLE, CREATE_NO_WINDOW, or DETACHED_PROCESS. In this case, the child's standard handles are implicitly duplicated from the parent if the child shares the parent's console session. Contra "1227748.patch", the standard handles are not "attached to the console window". For example, if the parent's stdout is redirected to a handle for an open disk file, the child's stdout will be redirected to the same open file. It has nothing to do with a window, and the console session doesn't even need to have a window (i.e. created with CREATE_NO_WINDOW; or a pseudoconsole session). In particular, if the executable image of the child is a console application, the system duplicates the parent's standard handles to the child, as well as a handle for the parent's console session, if any. If the child can connect to the parent's console at startup, then the duplicated standard handles are used, whatever they are. (In general, they need to be handles for pipe, character, or disk files opened in synchronous mode, as required by C standard I/O.) If the child can't connect to a console session, it allocates a new console and opens the console "Input" and "Output" as its standard handles. On the other hand, if the executable image of the child is not a console application, the system does not implicitly duplicate standard handles from the parent to the child. The window manager and graphical shell even explicitly reuse the standard-handle values (via STARTUPINFO) to implement features that aren't I/O file related when running GUI apps, including configuring an activation hotkey (stdin) or passing a handle for the preferred output monitor (stdout). ---------- nosy: +eryksun _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue1227748> _______________________________________

1 0

[issue43958] Importlib.metadata docs claim PackagePath is a Path subclass
by Paul Moore April 29, 2021

April 29, 2021

New submission from Paul Moore <p.f.moore(a)gmail.com>: The importlib.metadata documentation states that the PackagePath class is "a pathlib.Path derived object". This isn't true - it's a PurePath subclass, and in particular it does not have a resolve() method. In fact, it has an undocumented custom locate() method that converts it into a Path object. I propose changing the documentation to make it clear that it is a PurePath subclass, and explicitly documenting the locate() method. ---------- assignee: docs@python components: Documentation messages: 392123 nosy: docs@python, paul.moore priority: normal severity: normal status: open title: Importlib.metadata docs claim PackagePath is a Path subclass type: behavior versions: Python 3.10 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue43958> _______________________________________

2 2