Mailman 3 October 2019 - docs

[issue18767] csv documentation does not note default quote constant
by Brian McLaughlin 14 Mar '21

14 Mar '21

New submission from Brian McLaughlin: Documentation should note default quoting behavior of the csv module is csv.QUOTE_MINIMAL http://hg.python.org/cpython/file/tip/Modules/_csv.c#l420 ---------- assignee: docs@python components: Documentation files: doc.patch keywords: patch messages: 195448 nosy: bemclaugh, docs@python priority: normal severity: normal status: open title: csv documentation does not note default quote constant 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/file31333/doc.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue18767> _______________________________________

4 3

[issue34538] Remove encouragement to author a base class for all Exception subclasses in a module
by Nathaniel Manista 14 Mar '21

14 Mar '21

New submission from Nathaniel Manista <nathaniel(a)google.com>: https://docs.python.org/3.8/tutorial/errors.html (and all other versions of that page back at least as far as 2.7) currently contain the guidance "When creating a module that can raise several distinct errors, a common practice is to create a base class for exceptions defined by that module, and subclass that to create specific exception classes for different error conditions: <code example>". It may have seemed like a good idea at the time, but we now know from years of experience that this is an experiment that didn't pan out and we can consider this guidance a Now-Contraindicated Best Practice Of Yesteryear™. Modules define subclasses of Exception for lots of reasons. Some of those subclasses have no relation to one another except that they are subclasses of Exception. Some of those subclasses define Exception instances that are never raised by code in the module, but that are expected to be raised by code passed to and called by the module. Yes, there are times when a common base class may be appropriate - such as when an inheritance hierarchy and polymorphism that satisfy the Liskov Substitution Principle make sense for the Exception subclasses, and when the base class itself is used (such as when the base class is an item in the Raises: section of a function's doc string). But these cases aren't so common as to justify the advice being offered generally about all Exception subclass definitions. Exception subclasses are just classes. Advising that authors may wish to define a common base class for all Exception subclasses in a module is like advising authors that they may wish to define a common base class for all object subclasses in a module - it's very, very, very occasionally a good idea in the particular circumstances of a particular module's implementation, but very generally not. ---------- assignee: docs@python components: Documentation messages: 324286 nosy: Nathaniel Manista, docs@python priority: normal severity: normal status: open title: Remove encouragement to author a base class for all Exception subclasses in a module type: enhancement versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue34538> _______________________________________

8 15

[issue30435] Documentation either unclear or incorrect on comparisons between bytes and strings in Python 3
by ipatrol 13 Mar '21

13 Mar '21

New submission from ipatrol: https://docs.python.org/3/reference/expressions.html#comparisons says that "Strings and binary sequences cannot be directly compared." That would seem to me to imply that an equality between them would raise an exception, as also claimed by https://wiki.python.org/moin/BytesStr However, that is manifestly incorrect. Bytes and strings can be compared: they are always unequal. This appears to be a result of the operation falling through to the default comparison, which returns False since they are not identical objects. Equality is a comparison, though it is not an order comparison. A brief search of the word "cannot" in the documentation suggest that saying a certain thing cannot be done usually implies that attempting to do so anyway will raise an exception, typically a TypeError. That this is not the case for string-bytes comparisons should be mentioned. ---------- assignee: docs@python components: Documentation messages: 294200 nosy: docs@python, ipatrol priority: normal severity: normal status: open title: Documentation either unclear or incorrect on comparisons between bytes and strings in Python 3 type: behavior versions: 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/issue30435> _______________________________________

5 7

[issue18017] ctypes.PyDLL documentation
by Marc Brünink 13 Mar '21

13 Mar '21

New submission from Marc Brünink: The documentation for is not very clear regarding the usage of CDLL and PyDLL. Especially it is not obvious that you should use PyDLL whenever you call any function of the Python/C API. Since calling a Python/C API function without owning the GIL will most likely cause latent segfaults, I think it warrants a warning box in section 16.17.2.2 and maybe also somewhere prominent in http://docs.python.org/dev/c-api/intro.html. For section 16.17.2.2 I would put a box next the decription of CDLL saying something like: "The Python GIL is released before a function call. It is not safe to call any Pyhon/C API function within the loaded library without acquiring the GIL first. Thus, if the loaded library calls functions of the Python/C API, for example in case it creates and returns a new Python object, and does not manually acquire and release the GIL, use PyDLL instead." ---------- assignee: docs@python components: Documentation messages: 189629 nosy: Marc.Brünink, docs@python priority: normal severity: normal status: open title: ctypes.PyDLL documentation versions: Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue18017> _______________________________________

5 5

[issue27886] Docs: the difference between rename and replace is not obvious
by Andrew Svetlov 13 Mar '21

13 Mar '21

New submission from Andrew Svetlov: Hi. On reading the doc for pathlib I've stuck with `.rename()` and `.replace()` (https://docs.python.org/3/library/pathlib.html#pathlib.Path.rename). What's the difference? Going to pathlib's source code I've figured out that methods are use different functions from `os` module: `os.rename()` and `os.replace()`. But the documentation for `os` module is not obvious too: the docs for both functions are almost equal from my perspective, the only significant difference is that `os.rename()` suggests to use `os.replace()` for cross-compatibility. Could anybody explain the difference? Also, at least the doc for `pathlib.Path.rename` worth to have a sentence like borrowed from `os.rename`: "If you want cross-platform overwriting of the destination, use replace()." ---------- assignee: docs@python components: Documentation keywords: easy messages: 273836 nosy: asvetlov, docs@python, pitrou priority: low severity: normal status: open title: Docs: the difference between rename and replace is not obvious type: behavior versions: Python 3.4, Python 3.5, Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue27886> _______________________________________

4 8

[issue25741] Usual Installation Directory
by Firat Ozgul 12 Mar '21

12 Mar '21

New submission from Firat Ozgul: Official documentation reads: "On Windows machines, the Python installation is usually placed in C:\Python35" However, as of Python 3.5.0, usual installation directory on Windows is %LOCALAPPDATA%\Programs\Python. ---------- assignee: docs@python components: Documentation messages: 255455 nosy: docs@python, firatozgul priority: normal severity: normal status: open title: Usual Installation Directory type: enhancement versions: Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue25741> _______________________________________

6 10

[issue31427] Proposed addition to Windows FAQ
by Stephan Houben 12 Mar '21

12 Mar '21

New submission from Stephan Houben: Several people have asked on python-list why they are running into these errors. Python 3.6.0 can't start because api-ms-win-crt-runtime-l1-1-0.dll is missing. The solution is to install KB 2999226 "Update for Universal C Runtime in Windows". https://support.microsoft.com/en-us/help/2999226/update-for-universal-c-run… Propose to add this as a Windows FAQ. ---------- assignee: docs@python components: Documentation messages: 301952 nosy: Stephan Houben, docs@python priority: normal severity: normal status: open title: Proposed addition to Windows FAQ type: enhancement versions: Python 3.6, Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue31427> _______________________________________

4 5

[issue15097] Improving wording on the thread-safeness of import
by Merlijn van Deen 09 Mar '21

09 Mar '21

New submission from Merlijn van Deen <valhallasw(a)gmail.com>: http://docs.python.org/library/threading.html#importing-in-threaded-code Currently, the documentation states "Firstly, other than in the main module, an import should not have the side effect of spawning a new thread and then waiting for that thread in any way. Failing to abide by this restriction can lead to a deadlock if the spawned thread directly or indirectly attempts to import a module." which, I think, fails to make the main point: a call to import acquires the import lock. A call to import from a second thread will thus block. As such, I would suggest rephrasing it to something like: "Firstly, an import acquires the import lock for that thread. Therefore, the import should not have the side effect of waiting for a different thread in any way, as this can lead to a deadlock if that thread directly or indirectly attempts to import a module." There are two additional points that might be interesting to note: (1) Any module can be imported. If the import causes a deadlock, that is a bad thing. Every module *will* be imported by tools such as nosetests. (1b) so: never, ever, have code that causes locks in a different thread in module level code witout 'if __name__=="__main__" ' blocks? (2) The lock is also acquired if a module has already been imported. For instance, in import sys # (1) def f(): import sys # (2) the import lock is acquired in (1) /and/ (2). Adding example code and/or a flow diagram might be a bit too much, but it does clarify how easy it is to make this mistake. See the attached for an example (both a simple example script, as well as a flow diagram explaining what happens). ---------- assignee: docs@python components: Documentation files: deadlock.py messages: 163068 nosy: docs@python, valhallasw priority: normal severity: normal status: open title: Improving wording on the thread-safeness of import type: enhancement Added file: http://bugs.python.org/file26037/deadlock.py _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue15097> _______________________________________

3 6

[issue30295] msvcrt SetErrorMode not documented
by Giampaolo Rodola' 06 Mar '21

06 Mar '21

New submission from Giampaolo Rodola': Also SEM_FAILCRITICALERRORS and other SEM_constants. They should as setting error mode on Windows for console applications is a pretty common use case (in fact ./Lib/test/libregrtest/setup.py uses it). ---------- assignee: docs@python components: Documentation messages: 293189 nosy: docs@python, giampaolo.rodola priority: normal severity: normal status: open title: msvcrt SetErrorMode not documented versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue30295> _______________________________________

2 3

[issue8557] subprocess portability issue
by Dave Abrahams 05 Mar '21

05 Mar '21

New submission from Dave Abrahams <dave(a)boostpro.com>: On POSIX systems, the PATH environment variable is always used to look up directory-less executable names passed as the first argument to Popen(...), but on Windows, PATH is only considered when shell=True is also passed. Actually I think it may be slightly weirder than that when shell=False, because the following holds for me: C:\>rem ##### Prepare minimal PATH ##### C:\>set "PATH=C:\Python26\Scripts;C:\Python26;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem" C:\>rem ##### Prepare a minimal, clean environment ##### C:\>virtualenv --no-site-packages e:\zzz New python executable in e:\zzz\Scripts\python.exe Installing setuptools................done. C:\>rem ##### Show that shell=True makes the difference in determining whether PATH is respected ##### C:\>python Python 2.6.5 (r265:79096, Mar 19 2010, 18:02:59) [MSC v.1500 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import subprocess >>> subprocess.Popen(['python', '-c', 'import sys; print sys.executable']) <subprocess.Popen object at 0x0000000001DBE080> >>> C:\Python26\python.exe >>> subprocess.Popen(['python', '-c', 'import sys; print sys.executable'], env={'PATH':r'e:\zzz\Scripts'}) <subprocess.Popen object at 0x0000000001F05A90> >>> C:\Python26\python.exe >>> subprocess.Popen(['python', '-c', 'import sys; print sys.executable'], env={'PATH':r'e:\zzz\Scripts'}, shell=True) <subprocess.Popen object at 0x0000000001F05B00> >>> e:\zzz\Scripts\python.exe That is, it looks like the environment at the time Python is invoked is what counts unless I pass shell=True. I don't even seem to be able to override this behavior by changing os.environ: you can clear() it and pass env={} and subprocess.Popen(['python']) still succeeds. This is a very important problem for portable code and one that took me hours to suss out. I think: a) the current behavior needs to be documented b) it needs to be fixed if possible c) otherwise, shell=True should be the default ---------- assignee: docs@python components: Documentation messages: 104422 nosy: dabrahams, docs@python priority: normal severity: normal status: open title: subprocess portability issue type: behavior versions: Python 2.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue8557> _______________________________________

8 23