[IPython-dev] Multiple outputs per input line
Brian Granger
ellisonbg at gmail.com
Mon Mar 14 13:01:04 EDT 2011
Hi,
>> I think that would get quite difficult. Mathematica's notion of
>> output is very specific and concrete (they basically trigger a
>> displayhook on every assignment). Our notion of "output" now is very
>> dynamic - especially when you mix multiple frontends into the picture.
>>
>
> Remember, we're talking here about the outputs that get produced by
> the displayhook, for those we do have numbers we can track (because
> they stem from sys.displayhook firing). You're completely correct
> that we can't number display side effects, like print statements or
> any of the products of the new display system. But the return value
> of computations, which is what Out[N] contains, we can track.
I am a bit confused then. I thought we had removed the possibility
for displayhook to be called more than once per input. I seem to
remember that you removed that when you were working on the input
splitter and execution logic last summer. What am I missing. I do
agree that it is a bit different if we are only talking about the
displayhook part of the logic.
> The logic for getting mathematica-like numbering is pretty easy:
>
> - prior to code execution, the kernel sets an offset in the display hook to 0.
> - on each call to displayhook, it does:
> execution_counter += offset
> offset+=1
Yep.
> With this, in all cases where only a single call is made to
> displayhook get matching numbers, but if a displayhook fires multiple
> times for a single input, then the counter is incremented accordingly.
This is definitely an unambiguous way of handling it. I have always
found it a bit awkward to have Out incrementing this way in
Mathematica though.
> This would let us have always unambiguous storage of outputs by number
> even if multiple outputs were produced. The only change would be that
> in such a scenario, the next input wouldn't be 'previous+1' but
> instead it would be incremented by as many outputs as came out.
Right.
> Because Python isn't a purely functional language, we'll always have a
> distinction between the Out[] things that we can see go by on
> displayhook and other uncontrolled side-effects (prints, plots, etc).
> But so far, having numbered outputs for functional results has served
> us well, so this would simply be a matter of refining that to better
> handle the multi-output cases (which today we don't handle very well,
> as Thomas discovered).
I agree, but let's clarify why the multiple Out per In is even
relevant (I thought it was impossible now).
Cheers,
Brian
> Cheers,
>
> f
>
--
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com
More information about the IPython-dev
mailing list