Mailman 3 December 2020 - docs

[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

[issue42705] Intercepting thread lock objects not working under context managers
by Mohamad Kanj 17 Jan '21

17 Jan '21

New submission from Mohamad Kanj <mhmd.kanj(a)gmail.com>: The interception of Python and C functions is achieved through the `sys` module - however, when using thread locks from `threading` module for instance under context managers, the calls on the lock to `acquire()` and `release()` cannot be witnessed. If these methods were to be called explicitly then this is no problem. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue42705> _______________________________________

3 3

[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

[issue42783] asyncio.sleep(0) idiom is not documented
by Simon Willison 07 Jan '21

07 Jan '21

New submission from Simon Willison <swillison(a)gmail.com>: asyncio.sleep(0) is the recommended idiom for co-operatively yielding control of the event loop to another task: https://github.com/python/asyncio/issues/284 and https://til.simonwillison.net/python/yielding-in-asyncio This isn't currently explained in the documentation. ---------- assignee: docs@python components: Documentation, asyncio messages: 384025 nosy: asvetlov, docs@python, simonw, yselivanov priority: normal severity: normal status: open title: asyncio.sleep(0) idiom is not documented type: enhancement _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue42783> _______________________________________

3 4

[issue42179] Clarify chaining exceptions in tutorial/errors.rst
by Vladimir Ryabtsev 06 Jan '21

06 Jan '21

New submission from Vladimir Ryabtsev <greatvovan(a)gmail.com>: A new section has been added to the page as a result of https://bugs.python.org/issue37826. The change: https://github.com/python/cpython/commit/dcfe111eb5602333135b8776996332a8dc… The wording it uses (in the beginning of section 8.5), defines chaining as setting __cause__ attribute in an exception, and later states that "Exception chaining happens automatically when an exception is raised inside an exception handler or finally section". This may lead the reader to a wrong idea that re-raising an exception without "from" in "except" and "finally" automatically sets __cause__. In reality it sets only __context__ attribute, which is similar concept to __cause__, but work a bit differently, as explained in library/exceptions.rst. I suggest to mention that difference and provide a link to the main article. ---------- assignee: docs@python components: Documentation messages: 379823 nosy: Vladimir Ryabtsev, docs@python priority: normal severity: normal status: open title: Clarify chaining exceptions in tutorial/errors.rst versions: Python 3.10, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue42179> _______________________________________

7 19

[issue38413] Remove or change "Multithreading" section
by Vladimir Ryabtsev 06 Jan '21

06 Jan '21

New submission from Vladimir Ryabtsev <greatvovan(a)gmail.com>: This is regarding the page https://docs.python.org/3.7/library/sqlite3.html. I believe this section on the very bottom of the page has been kept here for pretty long time, during that both SQLite and the sqlite3 module evolved and improved. Now the content contradicts to the description of function "connect()" in the part describing "check_same_thread" parameter. The function description says that using connections from multiple threads is allowed with serialization handled by the user (and it is true), while the bottom "Mutithreading" section says sharing connections is not allowed. I think we can remove "Mutithreading" section entirely unless there is something important to add to what already mentioned. ---------- assignee: docs@python components: Documentation messages: 354227 nosy: Vladimir Ryabtsev, docs@python priority: normal severity: normal status: open title: Remove or change "Multithreading" section versions: Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue38413> _______________________________________

6 15

[issue42528] Improve the docs of most Py*_Check{,Exact} API calls
by Antonio Cuni 06 Jan '21

06 Jan '21

New submission from Antonio Cuni <anto.cuni(a)gmail.com>: I think that none of these API calls can fail, but only few of them are documented as such. E.g. PyNumber_Check contains the sentece "This function always succeeds" but PyBytes_Check does not. ---------- assignee: docs@python components: Documentation messages: 382269 nosy: antocuni, docs@python priority: normal severity: normal status: open title: Improve the docs of most Py*_Check{,Exact} API calls type: enhancement _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue42528> _______________________________________

3 5