ApplicationCommunicator cancels the application future unnecessarily?

[fish-face]

ApplicationCommunicator cancels the application future unnecessarily?

[andrewgodwin]

At this point I don't recall why that's there; I can only presume my past self had some reasoning, but I don't know at this point and I'd have to go spend a few hours re-learning that specific code to see if there is something.

It's possible this was more necessary in prior Python versions, too; async in the 3.6 era needed a lot more workarounds.

[fish-face]

Well this was the commit which added it daebab1 - don't know if you already checked that :P

I guess what I was hoping to understand was something a bit more general, though 6 years ago is a long time even for that - whether there was an underlying assumption that if you timed out waiting for output that ought to be fatal, and if so any rationale or anything around that.

I do notice from looking at that commit a second time that the same change is performed in wait() and in receive_output() - to me this makes more sense because you were waiting for the task to finish anyway. So maybe the behaviour could've been transferred to the receive_output case? But, my first assumption would still have been that you could wait with a timeout and then the task should be left alone if the timeout elapses.

[andrewgodwin]

Yes, I'm afraid that a one line commit message from 6 years ago does not restore my memory in this particular case. If you can prove it's not needed via some tests or something, I'd be happy to remove it.