[IPython-dev] Fwd: [Matplotlib-users] Improved dashing for black and white plots?

[Walter Dörwald]

Fernando Perez wrote:
> On 7/13/06, Ville Vainio <vivainio at gmail.com> wrote:
>> > BTW, here is a version of history as a ipipe table:
>>
>> I think we should convert most of the magics to return a table if they
>> currently dump tabular/linear data to screen.
> 
> Sounds good.  I know you guys have put much more work/interest than me
> in the whole shell-type usage, and this would be a very nice way of
> really making ipython a really interesting tool on that front.
> 
> My only concern here is lazy evaluation: in a shell,
> 
> ls * | grep foo
> 
> produces results from grep as early as they get created by ls.  A
> simple implementation in python will most likely lead to a greedy
> design which would block.  It can be done with generators, though.
> You just need to find a mechanism such that the generators, when
> chained for processing, operate in lazy mode,

That already works (if you're using ibrowse as the output, i.e. if you
have curses). For example try:
   ix("ls -l -R") | ifilter("_.endswith('.py')")
This starts output right away (once it finds the first Python file).
However if the command executed does some output it messes up the
screen. Maybe subprocess is the solution for that?

You can even use non-terminating generators:
itertools.count() | ifilter("_ % 23 == 0")

> but to consume them in
> full if they are just going to be printed as output.

This depends on the display object you're using. ibrowse only fetches
enough items from the generator to fill the first screen. Only when you
scroll down does it fetch more.

If you're using idump (e.g. sys.modules | idump) the output will start
once the input generator has been consumed. The reason for that is that
idump needs to be able to determine the column widths.

> This can be
> achieved by ensuring that their __repr__ (invoked at display time)
> consumes them completely before rendering them.

ipipe doesn't do it directly via __repr__. Instead it installs a display
hook that handles objects it knows about.

> There are a few subtleties, but I think this can be both a fun and
> very useful development.  I won't get dragged into it, though :)

What I don't know anything about is how
  ls * | grep foo
would be turned into
  ix("ls *") | igrep("foo")
(or something similar that is a proper Python expression).

Servus,
   Walter