This way, you would not have to wait for all messages to be displayed after you open your laptop in the morning when you run an simulation overnight on the cluster.
notice this is a proof of concept, the randomness is not really important, but could be removed with if we keep track of the last printed message. Also it depends on status.comm.kernel.iopub_thread._events which I suppose is meant for internal usage (indicated by the underscore before _events.
Both these should be possible to mitigate when more time is spend on those parts.
