Kyle Stanley <aeros...@gmail.com> added the comment: > I’m a bit disappointed, since it looks like this won’t allow implementing the > OP’s classes without using private APIs. The debugging and loggin use cases > aren’t very compelling to me.
Yeah, I had every intention when I initially proposed the idea on the python-ideas thread to provide an extensive means of implementing custom Future and Executor classes, but Antoine brought up a very valid concern about users shooting themselves in the foot with it: > I'm much more lukewarm on set_state(). How hard is it to reimplement > one's own Future if someone wants a different implementation? By > allowing people to change the future's internal state, we're also > giving them a (small) gun to shoot themselves with. In terms of a cost-benefit analysis, I'd imagine that it's going to be a rather small portion of the concurrent.futures users that would actually have a genuine use case for implementing their own custom Future or Executor. He was still approving of a `future.state()` though, which is why I considered implementing it alone: > That sounds useful to me indeed. I assume you mean something like a > state() method? We already have Queue.qsize() which works a bit like > this (unlocked and advisory). Although not nearly as significant (or interesting), I've personally encountered situations where it would be useful for logging purposes to be able to read the approximate state of the future. But if the consensus ends up being that it's not useful enough to justify adding compared to the original purpose of the issue, I would certainly understand. ---------- _______________________________________ 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
