Mailman 3 October 2020 - docs

[issue42041] venv subprocess call to python resolves to wrong interpreter
by Eryk Sun 18 Oct '20

18 Oct '20

Eryk Sun <eryksun(a)gmail.com> added the comment: > Also, why would we document the Windows rules, but not the POSIX > rules? They are arguably just as strange to someone who doesn't > know them. POSIX rules are simply to search PATH for the filename as passed, and if it has a slash in it, the path is resolved against the working directory. There is no implicit search of the application directory, current directory, and system directories. There is no search for "dir/file" in *every* search path directory instead of just resolving against the working directory. There is no figuring out when ".exe" or PATHEXT extensions will be appended or how to search for a filename that has no extension by appending a trailing "." to the name. And there is no massive inconsistency between the search semantics of shell=True and shell=False. What happens with "platform semantics" in Windows is complicated compared to POSIX. I'm more comfortable telling people to search via shutil.which() than relying on the platform search. I'd be much more comfortable if that's what subprocess.Popen() just did on its own. But we're locked into platform semantics, and I don't see that changing. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue42041> _______________________________________

1 0

[issue42041] venv subprocess call to python resolves to wrong interpreter
by Paul Moore 18 Oct '20

18 Oct '20

Paul Moore <p.f.moore(a)gmail.com> added the comment: Well, I'm not convinced that using `shutil.which` is the right answer for anything other than "python". And even there, I'd recommend using `sys.executable` over `shutil.which` in pretty much every case. My view is that if we ignore the "weirdness" introduced by the redirector[1], for everything else `subprocess` is fine - it searches for the executable using the normal platform semantics. That's nearly always the same across platforms, and when it isn't, users may well prefer consistency with the platform over identical cross-platform behaviour. And if they *do* want cross-platform consistency, at the cost of occasional differences between their program's behaviour and (for example) the shell, then they have `shutil.which` available. Saying that `subprocess` follows platform semantics is easy, and clear. People who need to know platform details can find them out. People who want Python-defined cross-platform semantics have `shutil.which`. That's the basis on which I feel that documenting the Windows rules is unnecessary. Also, why would we document the Windows rules, but not the POSIX rules? They are arguably just as strange to someone who doesn't know them. [1] I would characterise that weirdness as being that the redirector impacts the behaviour of how the platform locates the "python" command under the platform search rules of the platform the redirector is used on - even though we don't document the behaviour of the redirector so the user cannot infer the actual rules without knowing implementation details. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue42041> _______________________________________

1 0

[issue42041] venv subprocess call to python resolves to wrong interpreter
by Eryk Sun 18 Oct '20

18 Oct '20

Eryk Sun <eryksun(a)gmail.com> added the comment: > I don't think we should document this level of detail But a lot of it -- most of it -- is also strange behavior that no one would expect without reading about it somewhere. Most users of subprocess.Popen() will never wade through the documentation of CreateProcessW, SearchPathW, ShellExecuteExW, and cmd.exe -- to the extent that the behavior is usefully and correctly documented by Microsoft. One of the reasons I bother writing it out in detail here is to make the case for always using shutil.which(), regardless of the value of `shell` (unless shell=True is being used beyond the filesystem scope). We have complete control of the implementation and documentation of shutil.which(). I don't want that advice to be narrowed down to just talking about running "python". ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue42041> _______________________________________

1 0

[issue42041] venv subprocess call to python resolves to wrong interpreter
by Paul Moore 18 Oct '20

18 Oct '20

Paul Moore <p.f.moore(a)gmail.com> added the comment: I don't think we should document this level of detail, both because it's basically Windows standard behaviour and therefore not up to us to document, and because it's *way* too overwhelming for the average user. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue42041> _______________________________________

1 0

[issue42041] venv subprocess call to python resolves to wrong interpreter
by Eryk Sun 18 Oct '20

18 Oct '20

Eryk Sun <eryksun(a)gmail.com> added the comment: I don't know how much should be documented for subprocess.Popen, but here are the details for how searching works with shell=False (default) and shell=True. For shell=False, the search path used by WinAPI CreateProcessW checks %__APPDIR__%; %__CD__% (unless %NoDefaultCurrentDirectoryInExePath% is defined and the name to search contains no backslashes); %SystemRoot%\System32; %SystemRoot%\System; %SystemRoot%; and then the %PATH% directories. The search path is passed to WinAPI SearchPathW, with a default ".exe" extension. SearchPathW tries to resolve a relative path (but not a drive-relative or rooted-relative path) against every directory in the search path, unless it explicitly begins with a "." or ".." component. For the relative case, it appends the default ".exe" extension to a name if and only if it has no extension (a trailing "." counts as an extension). For the non-relative case, it first tries to find the name as given and then with the default extension appended, even if the filename already has an extension (no exception is made for a trailing dot, i.e. searching for "C:\Temp\spam." will check for "spam." and then "spam..exe"). >From the POSIX perspective, the implicit inclusion of the application directory, working directory, and system directories is strange and, regarding the inclusion of the working directory, troubling. The fact that searching for a relative name with one or more slashes, such as "spam\\python", is not resolved against *only* the working directory is strange and not documented. The rules governing when ".exe" will be appended are complicated and incorrectly documented (e.g. the claim "if the file name contains a path, .exe is not appended"). With shell=True, the CMD shell simply checks %__CD__% (unless %NoDefaultCurrentDirectoryInExePath% is defined and the name to search contains no slashes) and %PATH%. Support for forward slash in the name to search is wonky; it works only for quoted paths. But at least a relative path that contains slashes is only resolved against the current working directory instead of every directory in the search path. CMD's rules for appending default extensions are simpler than SearchPathW in some ways, but also more complicated because it's generalized as the PATHEXT list of extensions. In each directory, CMD always looks first for the searched name as given and then the name plus each extension in PATHEXT, regardless of the filepath type or whether the searched name already has an extension. It will not find a name that has no extension unless PATHEXT includes a "." entry for the empty extension. (This is consistent with the desktop shell API, which supports defining an association for the "." filetype.) ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue42041> _______________________________________

1 0

[issue42041] venv subprocess call to python resolves to wrong interpreter
by Paul Moore 18 Oct '20

18 Oct '20

Paul Moore <p.f.moore(a)gmail.com> added the comment: OK, PR updated as per discussion. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue42041> _______________________________________

1 0

[issue41822] Document the mean of values for sys.float_info.rounds
by Raymond Hettinger 18 Oct '20

18 Oct '20

New submission from Raymond Hettinger <raymond.hettinger(a)gmail.com>: The current docs unnecessarily refer readers to the C99 standard. "integer constant representing the rounding mode used for arithmetic operations. This reflects the value of the system FLT_ROUNDS macro at interpreter startup time. See section 5.2.4.2.2 of the C99 standard for an explanation of the possible values and their meanings." The docs should quote the standard, "The rounding mode for floating-point addition is characterized by the implementation defined value of FLT_ROUNDS: -1 indeterminable, 0 toward zero, 1 to nearest, 2 toward positive infinity, 3 toward negative infinity. All other values for FLT_ROUNDS characterize implementation-defined rounding." behavior. ---------- assignee: docs@python components: Documentation keywords: newcomer friendly messages: 377236 nosy: docs@python, rhettinger priority: normal severity: normal status: open title: Document the mean of values for sys.float_info.rounds _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue41822> _______________________________________

5 8

documentation bug: format string for numbers.
by Cris Luengo 18 Oct '20

18 Oct '20

In this documentation page: https://docs.python.org/3.10/c-api/arg.html#arg-parsing <https://docs.python.org/3.10/c-api/arg.html#arg-parsing> there is this section: l (int <https://docs.python.org/3.10/library/functions.html#int>) [long int] Convert a Python integer to a C long int. k (int <https://docs.python.org/3.10/library/functions.html#int>) [unsigned long] Convert a Python integer to a C unsigned long without overflow checking. L (int <https://docs.python.org/3.10/library/functions.html#int>) [long long] Convert a Python integer to a C long long. K (int <https://docs.python.org/3.10/library/functions.html#int>) [unsigned long long] Convert a Python integer to a C unsigned long long without overflow checking. unsigned long should be "L" (this is what I see in a 64-bit unsigned NumPy array on macOS) and long long should be "k" (I presume, I can't make such an array on this machine, only on Windows, where long and int are identical, is long long meaningful). Note that, for all other types, the uppercase letter represents the unsigned type and the lowercase letter the signed type.

1 0

[issue41983] Missing Documentation AF_PACKET
by Darnel T. 18 Oct '20

18 Oct '20

New submission from Darnel T. <darnelgt33(a)gmail.com>: Python documentation said AF_PACKET exists, but when I looked at the python script it was missing on Mac and Windows. I'm currently on Windows. ---------- assignee: docs@python components: Documentation messages: 378331 nosy: TheNuGuy, docs@python priority: normal severity: normal status: open title: Missing Documentation AF_PACKET versions: Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue41983> _______________________________________

2 1

[issue32820] Add and document __format__ method for IPv[46]Address
by Eric V. Smith 17 Oct '20

17 Oct '20

Eric V. Smith <eric(a)trueblade.com> added the comment: I've created issue 42061 for the documentation. Hopefully marking that issue as easy and newcomer friendly will attract some attention. Thanks ewosborne and Serhiy for adding this feature, and everyone for their input. ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue32820> _______________________________________

2 1