| def __exit__(self, exc_type, exc_val, exc_tb):|
if exc_val is not None and self._cancel_on_error:
(I believe the above would have to be specified as an override for each of ThreadPoolExecutor and ProcessPoolExecutor if cancel_on_error were supplied as a parameter to the executor constructor. They both currently use the ``__exit__`` specified in the abstract Executor class, which wouldn't have access to cancel_on_error.)
My previous consideration about waiting for user input of cancel_futures after the release of 3.9, before adding cancel_on_error to the constructor still applies to some degree though. If it directly uses executor.shutdown() with cancel_futures set to True, the maintenance would be rather minimal. But, it would potentially risk adding an underutilized parameter to the executor constructor (which contributes to feature bloat).
> Hmm, it should be possible. Do you specifically mean cancelling the pending
> futures once a single one of the submitted functions raises an exception,
> or cancelling the pending futures when the Executor itself raises an
> exception (I.E. BrokenProcessPool)? I would assume the prior, since that
> seems more useful to me.
I was referring to any exception within the context manager of the executor, not the futures or just the executor's exceptions, something such as the following:
with ThreadPoolExecutor(cancel_on_error=True) as executor:
# Code here
Then if Executor.__exit__ detects an exception it would call shutdown with cancel_futures set to True.
Python-ideas mailing list -- firstname.lastname@example.org
To unsubscribe send an email to email@example.com
Message archived at https://firstname.lastname@example.org/message/OAMG4JUFK54FTAASHQG5WNAA7BU7KRS7/
Code of Conduct: http://python.org/psf/codeofconduct/