Mailman 3 May 2019 - docs

[issue22630] `concurrent.futures.Future.set_running_or_notify_cancel` does not notify cancel
by Ben Mather 07 May '19

07 May '19

New submission from Ben Mather: The documentation for the `set_running_or_notify_cancel` method on `concurrent.futures.Future` states that it will notify waiting threads and trigger callbacks after the `Future` has been cancelled, however currently this is done immediately by the call to `cancel`. Oddly waiters (private interface used to implement `wait` and `as_completed`) do follow the behaviour documented for callbacks (they are called in `set_running_or_notify_cancel`) which means that they are not equivalent to setting a callback on each future. I have attached three possible patches: 1) "change-callbacks.patch" - this changes the behaviour to match the documentation. 2) "change-docs.patch" - this fixes the documentation to match the current behaviour. 3) "change-docs-and-waiters.patch" - in addition to fixing the documentation, this also fixes the inconsistency between waiters and callbacks by invoking waiters' `add_cancelled` method in `cancel`. I believe moving to the documented behaviour (1) would be a mistake as currently `set_running_or_notify_cancel` and the `RUNNING` state can be skipped entirely allowing Futures to be used just as a way to send results. Should mention that I have a separate patch (which I will submit separately (or here?)) that re-implements `wait` and `as_completed` using only publicly exposed methods. This makes it possible to extend or replace `Future` without having to preserve its private interface. Unfortunately this slightly breaks compatibility due to the difference between waiters and callbacks. I thought it would be best to discuss this issue first as I don't believe the current behaviour is as intended. ---------- assignee: docs@python components: Documentation, Library (Lib) files: change-callbacks.patch keywords: patch messages: 229282 nosy: bwhmather, docs@python priority: normal severity: normal status: open title: `concurrent.futures.Future.set_running_or_notify_cancel` does not notify cancel versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5 Added file: http://bugs.python.org/file36908/change-callbacks.patch _______________________________________ Python tracker <report(a)bugs.python.org> <http://bugs.python.org/issue22630> _______________________________________

4 6

[issue28795] Misleading stating, that SIGINT handler is installed by default
by Jan Velecký 07 May '19

07 May '19

New submission from Jan Velecký: Hello, documentation (https://docs.python.org/2/library/signal.html) states, that Python by default installs SIGINT handler which cause KeyboardInterrupt. This is not true everytime according to implementation. "Python installs a small number of signal handlers by default: SIGPIPE ... and SIGINT is translated into a KeyboardInterrupt exception." It should also mention this "SIGINT is installed only, when default handler is set at startup.". Because user can run python script from non-interative shell as background task and SIGINT handler is not installed, regardless although user does not change Python default behaviour. Related SO: http://stackoverflow.com/questions/40775054/capturing-sigint-using-keyboard… ---------- assignee: docs@python components: Documentation messages: 281664 nosy: Jan Velecký, docs@python priority: normal severity: normal status: open title: Misleading stating, that SIGINT handler is installed by default type: behavior versions: Python 2.7, 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/issue28795> _______________________________________

3 10

[issue31968] exec(): method's default arguments from dict-inherited globals
by anthony shaw 06 May '19

06 May '19

anthony shaw <anthonyshaw(a)apache.org> added the comment: Added a PR for the documentation clarification. ---------- nosy: +anthonypjshaw _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue31968> _______________________________________

1 0

[issue31968] exec(): method's default arguments from dict-inherited globals
by anthony shaw 06 May '19

06 May '19

Change by anthony shaw <anthonyshaw(a)apache.org>: ---------- pull_requests: +13053 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue31968> _______________________________________

1 0

[issue32971] unittest.TestCase.assertRaises
by NODA, Kai 06 May '19

06 May '19

New submission from NODA, Kai <nodakai(a)gmail.com>: https://docs.python.org/dev/library/unittest.html#unittest.TestCase.assertR… > If only the exception and possibly the msg arguments are given, return a context manager so that the code under test can be written inline rather than as a function: > > with self.assertRaises(SomeException): do_something() > > When used as a context manager, assertRaises() accepts the additional keyword argument msg. Perhaps we don't need the second sentence on the `msg` argument which isn't adding anything new. Ideally it should be more clear when the method operates in context manager mode. ("If only" and "possibly" don't play nicely together.) Maybe along the lines of "If no callable was passed as an argument ..." ? I haven't looked in to the actual implementation yet... ---------- assignee: docs@python components: Documentation messages: 313061 nosy: docs@python, nodakai priority: normal severity: normal status: open title: unittest.TestCase.assertRaises versions: Python 3.8 _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue32971> _______________________________________

6 7

[issue24195] Add `Executor.filter` to concurrent.futures
by Brian Quinlan 06 May '19

06 May '19

Brian Quinlan <brian(a)sweetapp.com> added the comment: Hey Ethan, I'm really sorry about dropping the ball on this. I've been burnt out on Python stuff for the last couple of years. When we left this, it looked like the -1s were in the majority and no one new has jumped on to support `filter`. If you wanted to add this, I wouldn't object. But I've been inactive so long that I don't think that I should make the decision. ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue24195> _______________________________________

1 0

[issue33971] os.mknod is subject to "umask"
by James Stevens 06 May '19

06 May '19

New submission from James Stevens <james.stevens(a)jrcs.co.uk>: As per the underlying "libc" call, the node created with "mknod" is subjected to the user's current umask setting. This is not made clear in the Python documentation, but the "libc" documentation makes this clear (see attached). ---------- assignee: docs@python components: Documentation files: Selection_2018-06-26_003.png messages: 320490 nosy: docs@python, james_r_c_stevens priority: normal severity: normal status: open title: os.mknod is subject to "umask" versions: Python 3.6 Added file: https://bugs.python.org/file47653/Selection_2018-06-26_003.png _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue33971> _______________________________________

2 2

[issue26374] concurrent_futures Executor.map semantics better specified in docs
by Brian Quinlan 06 May '19

06 May '19

Change by Brian Quinlan <brian(a)sweetapp.com>: ---------- stage: -> resolved status: open -> closed _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue26374> _______________________________________

1 0

[issue26374] concurrent_futures Executor.map semantics better specified in docs
by Karthikeyan Singaravelan 06 May '19

06 May '19

Karthikeyan Singaravelan <tir.karthi(a)gmail.com> added the comment: I would propose closing since the original doc issue regarding order and map in Python 3 is resolved. Just to add there is a PR to make map less eager : https://github.com/python/cpython/pull/707/ ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue26374> _______________________________________

1 0

[issue26374] concurrent_futures Executor.map semantics better specified in docs
by Brian Quinlan 06 May '19

06 May '19

Brian Quinlan <brian(a)sweetapp.com> added the comment: Can we close this bug then? ---------- _______________________________________ Python tracker <report(a)bugs.python.org> <https://bugs.python.org/issue26374> _______________________________________

1 0