[IPython-dev] messaging protocol
ellisonbg at gmail.com
Mon Apr 11 00:09:32 EDT 2011
On Sat, Apr 9, 2011 at 11:18 PM, Robert Kern <robert.kern at gmail.com> wrote:
> On 2011-04-10 01:06 , Brian Granger wrote:
>> On Fri, Apr 8, 2011 at 2:05 PM, Robert Kern<robert.kern at gmail.com> wrote:
>>> On 4/8/11 3:32 PM, Fernando Perez wrote:
>>>> On Fri, Apr 8, 2011 at 1:21 PM, Thomas Kluyver<takowl at gmail.com> wrote:
>>>>> In fact, now that we're using AST instead of code blocks, we could actually
>>>>> do what you suggest. We could check the last node, and only run it
>>>>> interactively if it was a single expression. Whether or not that's what we
>>>>> want to do, I don't know: any views?
>>>> That's a very good point. The fragile heuristics we had were
>>>> precisely because we lacked this information. But I really do like
>>>> this suggestion, because I think it provides the most intuitive
>>>> semantics. Things like:
>>>> for i in range(10):
>>>> won't produce 10 different Out outputs, and yet any last-block
>>>> expression, even if it contains some multline string or other complex
>>>> formatting that makes it be more than one *line of text* will still be
>>>> executed interactively, yielding just one result.
>>>> I'm very much +1 on this idea. Big benefit of your recent tackling
>>>> inputsplitter!! Awesome.
>>> I don't think we need to solve this in the splitter. You can do everything you
>>> need to do in the display trap. The logic is very simple. The display trap sets
>>> the displayhook before the code In[N] is executed. Every time the displayhook
>>> gets called during this execution, the display trap records the object and its
>>> formatted representation, overwriting whatever was there. Once the execution is
>>> done, *then* the formatted representation is given to the reply message (or
>>> printed if in the terminal frontend) and the history DB (if it is storing
>>> outputs), and the object is shoved into Out[N]. Then the display trap is cleared
>>> before In[N+1] is executed.
>> This is a good point that is worth investigating. The only hitch is
>> that the formatted representation is not sent in the reply to the
>> original code execution request. It is published over the PUB socket,
>> which makes sure that gets sent to all frontends. This means that the
>> display hook data can be sent out to all frontends *before* the
>> execute reply message goes back. But we might still be able to get
>> this to work. It is attractive because it would be this logic out of
>> the splitter, where it seems a bit out of place.
> Replace "reply message" with "displayhook PUB message" in what I wrote. You just
> need to explicitly tell the DisplayHook when to actually send the message/print
> the repr in the actual execution cycle. It should not do it on every __call__.
> That's all. That was the design I had in the ipwx prototype way back when.
I don't think it is that simple as the display hook PUB message gets
send out immediately:
a = 10
a # the PUB message happens here, before blocks are done being executed
Thus, the display hook *can't* have the information it needs to make
the decision about what to publish. Upon further thinking, I don't
see how we can get around this.
> Robert Kern
> "I have come to believe that the whole world is an enigma, a harmless enigma
> that is made terrible by our own mad attempt to interpret it as though it had
> an underlying truth."
> -- Umberto Eco
> IPython-dev mailing list
> IPython-dev at scipy.org
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu and ellisonbg at gmail.com
More information about the IPython-dev