Mailman 3 December 2017 - docs

[issue28697] asyncio.Lock, Condition, Semaphore docs don't mention `async with` syntax
by Ulrich Petri Dec. 20, 2017

Dec. 20, 2017

New submission from Ulrich Petri: The docs for asyncio's Lock, Condition and Semaphore should use the new clean `async with lock:` syntax instead of the older (and IMO rather ugly) `with (yield from lock):` version. ---------- assignee: docs@python components: Documentation, asyncio messages: 280861 nosy: docs@python, gvanrossum, ulope, yselivanov priority: normal severity: normal status: open title: asyncio.Lock, Condition, Semaphore docs don't mention `async with` syntax versions: Python 3.5, Python 3.6, Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue28697> _______________________________________

2 1

[issue29344] sock_recv not detected a coroutine
by Andrew Svetlov Dec. 20, 2017

Dec. 20, 2017

Andrew Svetlov <andrew.svetlov(a)gmail.com> added the comment: sock_recv was converted into genuine coroutine in Python 3.7 Closing the issue. ---------- nosy: +asvetlov resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -Python 3.5, Python 3.6 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue29344> _______________________________________

1 0

[issue30492] 'make clinic' does not work for out of tree builds / clinic.py is not in the devguide
by Gregory P. Smith Dec. 20, 2017

Dec. 20, 2017

New submission from Gregory P. Smith: I never do in-tree builds anymore because they make me feel dirty and leave build artifacts cluttering up my source tree. make clinic does not work for out of tree builds. To reproduce: ~$ git clone ...cpython repo... ~$ mkdir build && cd build ~/build$ ../cpython/configure --with-pydebug ~/build$ make clinic ./python -E ./Tools/clinic/clinic.py --make ./python: can't open file './Tools/clinic/clinic.py': [Errno 2] No such file or directory Makefile:545: recipe for target 'clinic' failed make: *** [clinic] Error 2 Per https://docs.python.org/3/howto/clinic.html it looks like I can just manually run clinic.py on the files I have modified. Ideally the build system would take care of that for me. But all I really want is a single command that keeps me up to date. python3 Tools/clinic/clinic.py appears to be that command. Even if it isn't fixed for out of tree builds, use of clinic needs to be in the devguide. ---------- assignee: docs@python components: Argument Clinic, Documentation messages: 294604 nosy: docs@python, gregory.p.smith, larry priority: normal severity: normal stage: needs patch status: open title: 'make clinic' does not work for out of tree builds / clinic.py is not in the devguide type: compile error versions: Python 3.7 _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue30492> _______________________________________

4 7

[issue32306] Clarify map API in concurrent.futures
by Antoine Pitrou Dec. 20, 2017

Dec. 20, 2017

Antoine Pitrou <pitrou(a)free.fr> added the comment: I think the documentation is now clearer. Closing! ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue32306> _______________________________________

1 0

[issue32306] Clarify map API in concurrent.futures
by Antoine Pitrou Dec. 20, 2017

Dec. 20, 2017

Antoine Pitrou <pitrou(a)free.fr> added the comment: New changeset 4aa84e728565a15a82727b9b971126e355f47e9d by Antoine Pitrou (Miss Islington (bot)) in branch '3.6': bpo-32306: Clarify c.f.Executor.map() documentation (GH-4947) (#4948) https://github.com/python/cpython/commit/4aa84e728565a15a82727b9b971126e355… ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue32306> _______________________________________

1 0

[issue32306] Clarify map API in concurrent.futures
by Roundup Robot Dec. 20, 2017

Dec. 20, 2017

Change by Roundup Robot <devnull(a)psf.upfronthosting.co.za>: ---------- pull_requests: +4840 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue32306> _______________________________________

1 0

[issue32306] Clarify map API in concurrent.futures
by Antoine Pitrou Dec. 20, 2017

Dec. 20, 2017

Antoine Pitrou <pitrou(a)free.fr> added the comment: New changeset a7a751dd7b08a5bb6cb399c1b2a6ca7b24aba51d by Antoine Pitrou in branch 'master': bpo-32306: Clarify c.f.Executor.map() documentation (#4947) https://github.com/python/cpython/commit/a7a751dd7b08a5bb6cb399c1b2a6ca7b24… ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue32306> _______________________________________

1 0

[issue32306] Clarify map API in concurrent.futures
by Antoine Pitrou Dec. 20, 2017

Dec. 20, 2017

Change by Antoine Pitrou <pitrou(a)free.fr>: ---------- keywords: +patch pull_requests: +4839 stage: -> patch review _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue32306> _______________________________________

1 0

[issue32306] Clarify map API in concurrent.futures
by David Lukeš Dec. 20, 2017

Dec. 20, 2017

David Lukeš <dafydd.lukes(a)gmail.com> added the comment: Yes, sorry for not being quite clear the first time around :) I eventually found out about Pool.imap (see item 3 on list in OP) and indeed it fits my use case very nicely, but my point was that the documentation is somewhat misleading with respect to the semantics of built-in `map()` in Python 3. Specifically, I would argue that it is unexpected for a function which claims to be "Equivalent to map(func, *iterables)" to require allocating a list the length of the shortest iterable. Maybe a code example will make this clearer for potential newcomers to the discussion -- this is what I would expect to happen (= the behavior of built-in `map()` itself), yielding values from the iterable is interleaved with calls to the mapped function: ``` >>> def gen(): ... for i in range(3): ... print("yielding", i) ... yield i ... >>> def add1(i): ... print("adding 1 to", i) ... return i + 1 ... >>> list(map(add1, gen())) yielding 0 adding 1 to 0 yielding 1 adding 1 to 1 yielding 2 adding 1 to 2 [1, 2, 3] ``` This is what happens instead with `concurrent.futures.Executor.map()`: ``` >>> def my_map(fn, iterable): ... lst = list(iterable) ... for i in lst: ... yield fn(i) ... >>> list(my_map(add1, gen())) yielding 0 yielding 1 yielding 2 adding 1 to 0 adding 1 to 1 adding 1 to 2 [1, 2, 3] ``` ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue32306> _______________________________________

1 0

[issue32306] Clarify map API in concurrent.futures
by Antoine Pitrou Dec. 20, 2017

Dec. 20, 2017

Antoine Pitrou <pitrou(a)free.fr> added the comment: I see. So the problem you are pointing out is that the tasks *arguments* are consumed eagerly. I agree that may be a problem in some cases, though I think in most cases people are concerned with the *results*. (note that multiprocessing.Pool() has an imap() method which does what you would like) ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue32306> _______________________________________

1 0