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.