Skip to content

pyin/pyout message type names should be language-agnostic #2826

Closed
timo opened this Issue Jan 22, 2013 · 7 comments

4 participants

@timo
timo commented Jan 22, 2013

A few suggestions minrk and me came up with on irc:

(abridged)

< 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

@Carreau
IPython member
Carreau commented Jan 22, 2013

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.

@timo
timo commented Jan 22, 2013

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.

@Carreau
IPython member
Carreau commented Jan 22, 2013

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.

@minrk
IPython member
minrk commented Jan 22, 2013

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.

@ivanov
IPython member
ivanov commented Jul 13, 2013

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

@minrk
IPython member
minrk commented Jul 13, 2013

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.

@minrk
IPython member
minrk commented Jan 29, 2014

this will be closed by #4536.

@takluyver takluyver closed this in #4536 May 9, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.