docs October 2020

docs@python.org

14 participants
351 discussions

[issue35295] Please clarify whether PyUnicode_AsUTF8AndSize() or PyUnicode_AsUTF8String() is preferred
by Marcin Kowalczyk 05 Feb '21

05 Feb '21

New submission from Marcin Kowalczyk <qrczakmk(a)gmail.com>: The documentation is silent whether PyUnicode_AsUTF8AndSize() or PyUnicode_AsUTF8String() is preferred. We are under the assumption that both are acceptable for the given caller, i.e. the caller wants to access just the sequence of UTF-8 code units (e.g. for calling a C++ function which takes std::string_view or std::string as a parameter), and the caller either will copy the UTF-8 code units immediately or is willing to own a temporary object to ensure a lifetime of the UTF-8 code units. File comments in unicodeobject.h about PyUnicode_AsUTF8AndSize() have a warning: *** This API is for interpreter INTERNAL USE ONLY and will likely *** be removed or changed in the future. *** If you need to access the Unicode object as UTF-8 bytes string, *** please use PyUnicode_AsUTF8String() instead. The discrepancy between these comments and the documentation should be fixed. Either the documentation is correct and the comment is outdated, or the comment is correct and the documentation is lacking guidance. It is not even clear which function is better technically: - PyUnicode_AsUTF8String() always allocates the string. PyUnicode_AsUTF8AndSize() does not allocate the string if the unicode object is ASCII-only (this is common) or if PyUnicode_AsUTF8AndSize() was already called before. - If conversion must be performed, then PyUnicode_AsUTF8String() makes a single allocation, while PyUnicode_AsUTF8AndSize() first calls PyUnicode_AsUTF8String() and then copies the string. - If the string is converted multiple times, then PyUnicode_AsUTF8AndSize() caches the result - faster. If the string is converted once, then the result persists as long as the string persists - wastes memory. I see the following possible resolutions: 1a. Declare both functions equally acceptable. Remove comments claiming that PyUnicode_AsUTF8AndSize() should be avoided. 1b. 1a, and change the implementation of PyUnicode_AsUTF8AndSize() to avoid allocating the string twice if it needs to be materialized, so that PyUnicode_AsUTF8AndSize() is never significantly slower than PyUnicode_AsUTF8String(). 2a. Declare PyUnicode_AsUTF8String() preferred. Indicate this in the documentation. 2b. 2a, and provide a public interface to check and access UTF-8 code units without allocating a new string in case this is possible (I think PyUnicode_READY() + PyUnicode_IS_ASCII() + PyUnicode_DATA() + PyUnicode_GET_LENGTH() would work, but they are not documented; or possibly also check if the string has a cached UTF-8 representation without populating that cached representation), so that a combination of the check with PyUnicode_AsUTF8String() is rarely or never significantly slower than PyUnicode_AsUTF8AndSize(). ---------- assignee: docs@python components: Documentation, Interpreter Core, Unicode messages: 330249 nosy: Marcin Kowalczyk, docs@python, ezio.melotti, vstinner priority: normal severity: normal status: open title: Please clarify whether PyUnicode_AsUTF8AndSize() or PyUnicode_AsUTF8String() is preferred type: performance versions: Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue35295> _______________________________________

4 9

[issue20464] Update distutils sample config file in Doc/install/index.rst
by Zachary Ware 03 Feb '21

03 Feb '21

New submission from Zachary Ware: >From docs@: On Thu, Jan 16, 2014 at 2:56 AM, Peter Bröcker <peter.broecker(a)uni-koeln.de> wrote: > Hi, > > I have tried to set up the distutils config files for a custom module > installation. Using the suggested snippet from > > http://docs.python.org/2/install/ > > [install] > install-base=$HOME/python > install-purelib=lib > install-platlib=lib.$PLAT > install-scripts=scripts > install-data=data did not work for me. > > Instead, I had to add install-headers and additionally modify all paths > to include $base: > > [install] > install-base=/some/dir > install-purelib=$base/lib > install-platlib=$base/lib.$PLAT > install-scripts=$base/scripts > install-headers=$base/include > install-data=$base/data > > > I'm unsure if this is actually a bug, but I could only resolve this with > the help of this answer on stackoverflow: > http://stackoverflow.com/a/12768721 > > Best regards, > Peter ---------- assignee: docs@python components: Distutils, Documentation messages: 209829 nosy: docs@python, zach.ware priority: normal severity: normal stage: test needed status: open title: Update distutils sample config file in Doc/install/index.rst type: behavior versions: Python 2.7, Python 3.3, Python 3.4 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue20464> _______________________________________

3 4

[issue22401] argparse: 'resolve' conflict handler damages the actions of the parent parser
by paul j3 27 Jan '21

27 Jan '21

New submission from paul j3: When there's a conflict involving an argument that was added via 'parents', and the conflict handler is 'resolve', the action in the parent parser may be damaged, rendering that parent unsuitable for further use. In this example, 2 parents have the same '--config' argument: parent1 = argparse.ArgumentParser(add_help=False) parent1.add_argument('--config') parent2 = argparse.ArgumentParser(add_help=False) parent2.add_argument('--config') parser = argparse.ArgumentParser(parents=[parent1,parent2], conflict_handler='resolve') The actions of the 3 parsers are (from the ._actions list): (id, dest, option_strings) parent1: [(3077384012L, 'config', [])] # empty option_strings parent2: [(3076863628L, 'config', ['--config'])] parser: [(3076864428L, 'help', ['-h', '--help']), (3076863628L, 'config', ['--config'])] # same id The 'config' Action from 'parent1' is first copied to 'parser' by reference (this is important). When 'config' from 'parent2' is copied, there's a conflict. '_handle_conflict_resolve()' attempts to remove the first Action, so it can add the second. But in the process it ends up deleting the 'option_strings' values from the original action. So now 'parent1' has an action in its 'optionals' argument group with an empty option_strings list. It would display as an 'optionals' but parse as a 'positionals'. 'parent1' can no longer be safely used as a parent for another (sub)parser, nor used as a parser itself. The same sort of thing would happen, if, as suggested in the documentation: "Sometimes (e.g. when using parents_) it may be useful to simply override any older arguments with the same option string." In test_argparse.py, 'resolve' is only tested once, with a simple case of two 'add_argument' statements. The 'parents' class tests a couple of cases of conflicting actions (for positionals and optionals), but does nothing with the 'resolve' handler. ------------------------------ Possible fixes: - change the documentation to warn against reusing such a parent parser - test the 'resolve' conflict handler more thoroughly - rewrite this conflict handler so it does not modify the action in the parent - possibly change the 'parents' mechanism so it does a deep copy of actions. References: http://stackoverflow.com/questions/25818651/argparse-conflict-resolver-for-… http://bugs.python.org/issue15271 argparse: repeatedly specifying the same argument ignores the previous ones http://bugs.python.org/issue19462 Add remove_argument() method to argparse.ArgumentParser http://bugs.python.org/issue15428 add "Name Collision" section to argparse docs ---------- assignee: docs@python components: Documentation, Library (Lib), Tests messages: 226862 nosy: docs@python, paul.j3 priority: normal severity: normal status: open title: argparse: 'resolve' conflict handler damages the actions of the parent parser type: behavior versions: Python 3.5 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue22401> _______________________________________

3 15

[issue36675] Doctest directives and comments not visible or missing from code samples
by Steven D'Aprano 25 Jan '21

25 Jan '21

New submission from Steven D'Aprano <steve+python(a)pearwood.info>: (Apologies if this is the wrong place for reporting website bugs.) The website is not rendering doctest directives or comments, either that or the comments have been stripped from the examples. On the doctest page itself, all the comments are missing: https://docs.python.org/3/library/doctest.html#directives The first example says: >>> print(list(range(20))) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19] but without the directive, the test would fail. Screen shot attached. Doctest directives are also missing from here: https://docs.python.org/3/library/ctypes.html My browser: Firefox 45.1.1 Also checked with text browser "lynx". ---------- assignee: docs@python components: Documentation files: missing_directives.png messages: 340570 nosy: docs@python, steven.daprano priority: normal severity: normal status: open title: Doctest directives and comments not visible or missing from code samples type: behavior Added file: https://bugs.python.org/file48277/missing_directives.png _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36675> _______________________________________

12 21

[issue40745] Typo in library/typing
by Héctor Canto 23 Jan '21

23 Jan '21

New submission from Héctor Canto <hectorcanto(a)gmail.com>: I found a small typo here: https://docs.python.org/3.8/library/typing.html?highlight=typing#typing.New… I checked also in other 3.x versions and it is there too. Original: A helper function to indicate a distinct types to a typechecker, see NewType Possible solution (remove the "s" in types): A helper function to indicate a distinct type to a typechecker, see NewType ---------- assignee: docs@python components: Documentation messages: 369730 nosy: docs@python, hectorcanto priority: normal severity: normal status: open title: Typo in library/typing type: enhancement versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue40745> _______________________________________

5 9

[issue40304] Classes created using type() don't need to explicitly inherit from object
by Борис Верховский 22 Jan '21

22 Jan '21

New submission from Борис Верховский <boris.verk(a)gmail.com>: As far as I can tell, passing `(object,)` and `()` as the `bases` parameter to the 3-argument version of type() produces the same result, because classes inherit from `object` in Python 3: >>> type('X', (object,), dict(a=1)).__bases__ (<class 'object'>,) >>> type('X', (), dict(a=1)).__bases__ (<class 'object'>,) I just want to make sure I'm not missing something and update the documentation of `type()` to reflect that. ---------- assignee: docs@python components: Documentation messages: 366613 nosy: boris, docs@python priority: normal pull_requests: 18902 severity: normal status: open title: Classes created using type() don't need to explicitly inherit from object type: enhancement versions: Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue40304> _______________________________________

3 6

[issue36769] doc Document that fnmatch.filter supports any kind of iterable not just lists
by Andrés Delfino 20 Jan '21

20 Jan '21

New submission from Andrés Delfino <adelfino(a)gmail.com>: Documentation on fnmatch.filter says: Return the subset of the list of names that match pattern. It is the same as [n for n in names if fnmatch(n, pattern)], but implemented more efficiently. But the function actual accepts any kind of iterable. I think it should be documented. ---------- assignee: docs@python components: Documentation messages: 341198 nosy: adelfino, docs@python priority: normal severity: normal status: open title: doc Document that fnmatch.filter supports any kind of iterable not just lists type: enhancement versions: Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue36769> _______________________________________

4 8

[issue24711] Document getpass.getpass behavior on ^C
by Markus Unterwaditzer 11 Jan '21

11 Jan '21

New submission from Markus Unterwaditzer: getpass.getpass doesn't enter a newline when the user aborts input with ^C, while input/raw_input does. This behavior is surprising and can lead to mis-formatting of subsequent output. However, since this behavior exists since 2.7 and applications may have started to rely on it, I'd add a note to the documentation. ---------- assignee: docs@python components: Documentation messages: 247302 nosy: docs@python, untitaker priority: normal severity: normal status: open title: Document getpass.getpass behavior on ^C 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/issue24711> _______________________________________

2 2

[issue34804] Repetition of 'for example' in documentation
by Aydin 10 Jan '21

10 Jan '21

New submission from Aydin <bagiyevaydin(a)gmail.com>: In the documentation of Python 3.7.0 there is an error in the usage of the world 'for example'. ---------- assignee: docs@python components: Documentation files: Functional Programming HOWTO — Python 3.7.0 documentation.png messages: 326418 nosy: docs@python, rarblack priority: normal severity: normal status: open title: Repetition of 'for example' in documentation versions: Python 3.7 Added file: https://bugs.python.org/file47825/Functional Programming HOWTO — Python 3.7.0 documentation.png _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue34804> _______________________________________

5 6

[issue41742] Request for docs.python.org/3/library/configparser.html#exceptions improvement
by leveque 08 Jan '21

08 Jan '21

New submission from leveque <jean-francois.leveque(a)sorbonne-universite.fr>: Hi, docs.python.org/3/library/configparser.html#exceptions does not mention KeyError which is mentioned under https://docs.python.org/3/library/configparser.html#mapping-protocol-access and https://docs.python.org/3/library/configparser.html#customizing-parser-beha…. Could it be added ? Cheers, ---------- assignee: docs@python components: Documentation messages: 376551 nosy: docs@python, leveque priority: normal severity: normal status: open title: Request for docs.python.org/3/library/configparser.html#exceptions improvement type: enhancement versions: Python 3.10, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue41742> _______________________________________

3 2

← Newer
1
...
6
7
8
9
10
11
12
...
36
Older →

Jump to page:

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

docs October 2020