A few suggestions minrk and me came up with on irc:
< minrk> the obvious generic name is "output", but that's too ambiguous with side effect output
< minrk> eval_result, or result_output, or just result
< minrk> and eval_result technically isn't accurate
< minrk> what about displayhook? It's in reference to a name used in Python, but it's a generic concept
< timotimo> result_value?
< timotimo> i wouldn't be against calling it something with displayhook
< timotimo> maybe exec_value or exec_result would be more fitting, though?
< minrk> trouble is, there's also execute_reply, which is different
< minrk> it is essentially a display_data message with a different name
< minrk> so perhaps that is the key
< timotimo> hm, isn't the connection with the in[N]/out[N] the most interesting part of it?
< minrk> well, the most interesting part is the actual thing to display
< minrk> the only difference between a pyout message and a display_data message is whether a prompt is drawn to its left
< minrk> but they are still both associated with a given input
This make sens, but is it really important ? It is almost never exposed to user and would have to be changed in a lot of places to get right, it will also induce incompatibility.
Not that I'm against, but I'm just pondering the cost of a big change versus having a 'for historical reason' when asked.
Well, there's already a versioning mechanism in the current master, where the protocol version is transmitted.
Here's what I'd do:
If the frontend sends a kernel_info and gets no answer, assume "pyin"/"pyout".
If the frontend sends a kernel_info and the protocol version is too low, use "pyin"/"pyout".
If the frontend sends a kernel_info and the protocol version is high enough, use whatever's new.
Seems simple enough to me. There's still time to fix this before it gets really hard, even though it's just a minor annoyance.
There is much less places with occurences of pyout/pyerr/pyin than I expected and most of them will probably be function name.
I don't see any reason not to at least put 'pyerr/pyin/pyout' as variable defined somewhere and try to migrate...
I'm just concerned of project that will try to cover multiple versions of IPython format, for which it might be really painfull.
Nbconvert/viewer for example.
At this point in development, I would discourage any project from trying to maintain compatibility with multiple versions of the notebook, it's just too new. A simple message-type rename is not actually a huge deal, especially since there are probably zero places in any code in the world that actually pay any attention to pyin messages (outside IPython.parallel). So it's really just pyout here.
What I currently think is the best solution so far is to eliminate pyout entirely, and add a key to the display_data message to indicate that it is the prompt / cell result. Then there isn't even a new message to handle, it's just how we deal with the relationship of outputs and prompts.
I think this has been discussed now and I hope this proposed changed is in our pending set of changes for the next change in message spec - but that won't happen for 1.0 as far as I understand. So punting this to 2.0
That's exactly right - this is IPEP 13 (#3296), which part for 1.0 is done, and these particular changes will be in 2.0 with the notebook format update.
this will be closed by #4536.