[IPython-dev] Re: Changes to Notebook Format

[Robert Kern]

Hans Meine wrote:
> On Wednesday 03 August 2005 07:13, Robert Kern wrote:
> 
>>Any interleaving of stdout and stderr is an accident.
> 
> This is an extreme point of view. ;-)

Then allow me to rephrase: "Any specific interleaving of stdout and 
stderr is an accident."

>>The whole point of 
>>having two different streams is that they can be handled separately and
>>piped to two different locations.
> 
> I agree.
> 
>>stderr messages need to be written 
>>with that in mind for any piece of code.
> 
> Right, but..
> 
>>Usually, they are, [...]
> 
> ..I don't agree 100% here.
> 
> And it really *can* be misleading if the "order" is wrong (i.e. not 
> chronological) - people are just too used to it from e.g. system shells.

The shells don't do any interleaving. When stdout and stderr are both 
output semi-immediately to the same terminal, the outputs get 
interleaved somewhat arbitrarily thanks to buffering. In the reasonably 
common case where the two streams are piped to different things, no 
interleaving takes place at all. It's the latter case that the 
separation of stdout and stderr is designed to support. Use of stderr 
that doesn't work well with separate destinations is missing the point.

> It's still a feature in my perspective that's not too unimportant and I don't 
> see why it "complicates document generation".  Just because there is not 
> maximally one error, one output cell belonging to one input, but an ordered 
> alternating sequence?

Look at the code. It's dead simple (at least this bit) and works. At 
minimum, implementing an interleaved stdout and stderr means more work 
compared to doing nothing and using the current, working code. As 
currently implemented, to get the data, the document generator just 
looks up the number of the cell (the "NN" in "In [NN]" and "Out[NN]") 
and the type. To change that, you would have to look up the number of 
the cell, the type, and some other specifier to pick out the specific 
stdout/stderr datum. That extra information needs to be handled every 
time there's output, not just the few times that stdout and stderr are 
interleaved.

Alternatively, we can give up fine-grained selection of which elements 
are shown for a given cell number, but I think that's going to be a 
feature used quite often. I often want to suppress the Out or the stdout 
elements because they're too long, but keep the In element.

I hate being the killjoy all the time, and I'm not suggesting that this 
feature won't be worthwhile to implement eventually but that we have 
higher priorities right now. Use of stderr is relatively rare (outside 
of tracebacks which we catch by a different mechanism). Use of stderr 
that really needs a specific interleaving with stdout (which was never 
guaranteed anywhere else) to make sense is even rarer.

-- 
Robert Kern
rkern at ucsd.edu

"In the fields of hell where the grass grows high
  Are the graves of dreams allowed to die."
   -- Richard Harter