Kyle Stanley <aeros...@gmail.com> added the comment: > But note my response to Antoine at the time, mentioning that implementing > ‘as_completed()’ is impossible that way. Antoine then backtracked somewhat.
Ah, I had seen that but for some reason hadn't considered that Antoine might have also changed his stance on a means of modifying the state of the future: > > It's actually really hard to implement your own > > Future class that works > > well with concurrent.futures.as_completed() -- this is basically what > > complicated the OP's implementation. Maybe it would be useful to look into > > a protocol to allow alternative Future implementations to hook into that? > Ah, I understand the reasons then. Ok, it does sound useful to explore > the space of solutions. But let's decouple it from simply querying the > current Future state. In that case, I'll revert the title and leave the issue open for further discussion; but I'll hold off on any PRs until we have some consensus regarding the direction we want to go in with regards to potential new future protocols. Apologies for the misunderstanding, thanks for clarifying. :) I'd also be interested in hearing Brian Quinlain's thoughts on the matter. ---------- title: Read approximate state of concurrent.futures.Future -> Expand concurrent.futures.Future's public API _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue39645> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
