Mailman 3 December 2019 - docs

Bug report: regarding the write() method
by Christos Vasilakos 09 Dec '19

09 Dec '19

Dear sir or madam, We are students of the University of Ioannina in the Department of Computer Engineering and Computer Science and during our lecture we, together with our professor(Nikos Mamoulis), came across an interesting case on the subject of file writing in Python 3. Upon opening a file with 'r+', and then proceeding to read from it, when attempting to write in the same file, the write() method does not obey the "cursor" position in the said file which was set by the read method, meaning it appends the string at the end of the file instead of replacing characters as it does in Python2. Following is a screenshot of the code that causes the issue. With best regards, Christos Vasilakos Vasileios Akoutas

1 0

[issue38652] Remove/update provisional note for asyncio.BufferedProtocol
by Kyle Stanley 07 Dec '19

07 Dec '19

New submission from Kyle Stanley <aeros167(a)gmail.com>: In the documentation (https://docs.python.org/3.9/library/asyncio-protocol.html#buffered-streamin…) for asyncio.BufferedProtocol there is a provisional API note. This should be updated/removed for 3.8 and 3.9 since it became a part of the stable API in 3.8. Current: > New in version 3.7: Important: this has been added to asyncio in Python 3.7 on a provisional basis! This is as an experimental API that might be changed or removed completely in Python 3.8. I would propose to changing it to: > New in version 3.7. ---------- assignee: docs@python components: Documentation messages: 355739 nosy: aeros, asvetlov, docs@python, yselivanov priority: normal severity: normal status: open title: Remove/update provisional note for asyncio.BufferedProtocol versions: Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue38652> _______________________________________

6 10

Errors in the "Python Patterns - Implementing Graphs" essay
by Fadil Nohur 06 Dec '19

06 Dec '19

Hello there, I would like to report some issues in the "Python Patterns - Implementing Graphs" Python essay, which can be found here: https://www.python.org/doc/essays/graphs/ . The first issue I would like to report is a Py2/Py3 incompatibility issue. The first 3 functions in the essay; find_path(), find_all_paths() and find_shortest_path(); all use the line if not graph.has_key(start) . In these functions, graph is a dictionary. However, the has_keys() method has been removed from Python 3, so these functions do not work in Python 3. To update the functions for Python 3 compatibility, if not graph.has_key(start) should be replaced with if start not in graph . The second issue I would like to report is within the second version of find_shortest_path(), i.e. Eryk Kopczyński's version. Some background first: graph is a dictionary representing nodes connected to each other. The nodes in graph are currently represented by single letter strings, e.g. 'a', 'b', 'c'. etc. I would like to point your attention to the line q = deque(start) . Here, start is a node in the graph. This line is intended to initialise the deque with a starting node. It works perfectly with one-letter character nodes, correctly setting q to deque(['a']) . However, the line does not work with nodes that are strings longer than one character. Let start be the string 'YOU' instead. Instead of q being initialised as deque(['YOU']) , q is initialised as deque(['Y', 'O', 'U']) instead. This is incorrect and breaks the algorithm. To fix this issue, q = deque(start) should be replaced with q = deque([start]) . I hope this information helps you fix the issues in the Python graph essay. Please follow up with me if you have any questions. Thanks, Fadil Nohur

1 0

https://docs.python.org/3/library/random.html
by A N 05 Dec '19

05 Dec '19

The random section doesnt include "from random import randrange" anywhere before giving a bunch of examples that includes randrange. I figured it out after searching around the web, but that'd be super confusing for a new guy, please fix.

1 0

[issue9694] argparse required arguments displayed under "optional arguments"
by Géry 03 Dec '19

03 Dec '19

Géry <gery.ogam(a)gmail.com> added the comment: I have just run into the same issue here: https://bugs.python.org/issue38950 - I prefer Terry J. Reedy's "keyword arguments" as it is clear and consistent with "positional arguments". - But Steven Bethard 's "flag arguments" looks fine since it is well known to shell users. - Martin Panter's "options" looks okay since it is the standard name in GNU Coreutils (https://www.gnu.org/software/coreutils/manual/coreutils.html#Common-options). However I don't like it very much as it is still ambiguous: "options", like "optional arguments", still suggests something that is non required. And "options" is less consistent with "positional arguments" (nobody seems to have suggested "option arguments"). - Oliver Smith's "switches" does not look okay because it is not general enough since it is commonly restricted to Boolean arguments. Anyway, the first 3 solutions are better than the current "optional arguments". What is blocking the approval of Martin Panter's PR? ---------- nosy: +maggyero _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue9694> _______________________________________

1 0

[issue34344] Fix the docstring for AbstractEventLoopPolicy.get_event_loop
by Vlad Starostin 02 Dec '19

02 Dec '19

New submission from Vlad Starostin <drtyrsa(a)yandex.ru>: The docstring says "This may be None or an instance of EventLoop". But docs explicitly state that get_event_loop "must never return None". The same docstring is also in the example in docs: https://docs.python.org/3.6/library/asyncio-eventloops.html#customizing-the… I propose changing it to: def get_event_loop(self): """Get the event loop. Returns an instance of EventLoop or raises an exception. """ If the wording is ok, I'll make a PR. ---------- assignee: docs@python components: Documentation, asyncio messages: 323190 nosy: asvetlov, docs@python, drtyrsa, yselivanov priority: normal severity: normal status: open title: Fix the docstring for AbstractEventLoopPolicy.get_event_loop versions: Python 3.6, Python 3.7, Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue34344> _______________________________________

7 13

[issue37883] threading.Lock.locked is not documented
by Rémi Lapeyre 01 Dec '19

01 Dec '19

New submission from Rémi Lapeyre <remi.lapeyre(a)henki.fr>: As far as I can tell, it has never been documented. I'm not sure if it is deprecated but it has a docstring so it seems to me, that it just needs documentation in Doc/Library/threading.rst PS: I don't know how to set the beginner friendly flag. ---------- assignee: docs@python components: Documentation, Library (Lib) messages: 349923 nosy: docs@python, remi.lapeyre priority: normal severity: normal status: open title: threading.Lock.locked is not documented type: enhancement versions: Python 3.7, Python 3.8, Python 3.9 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue37883> _______________________________________

5 16

[issue28805] Add documentation for METH_FASTCALL
by Stefan Krah 01 Dec '19

01 Dec '19

New submission from Stefan Krah: It looks like METH_FASTCALL gives nice speedups (#28754). Is this an internal interface or can it be documented like METH_KEYWORDS etc.? ---------- assignee: docs@python components: Documentation messages: 281766 nosy: docs@python, haypo, serhiy.storchaka, skrah priority: normal severity: normal stage: needs patch status: open title: Add documentation for METH_FASTCALL type: enhancement versions: Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue28805> _______________________________________

8 16