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

[Walter Dörwald]

Fernando Perez wrote:
> Hey guys,
> 
> in case one of you wants to have a serious go at this idea.  I think
> it would be pretty cool, but it's not completely trivial to implement.
>  Capturing of stdout of external and extension code requires proper
> handling of the underlying file descriptors.  Here's some code Robert
> Kern wrote a while ago to do this:
> 
> 
> import os
> import sys
> 
> STDOUT = 1
> STDERR = 2
> 
> class Redirector:
> [...]
> 
> ---------- Forwarded message ----------
> From: Fernando Perez <fperez.net at gmail.com>
> Date: Jul 12, 2006 12:11 AM
> Subject: Re: [Matplotlib-users] Improved dashing for black and white plots?
> To: John Hunter <jdhunter at ace.bsd.uchicago.edu>
> Cc: matplotlib-users <matplotlib-users at lists.sourceforge.net>
> 
> 
> On 7/11/06, John Hunter <jdhunter at ace.bsd.uchicago.edu> wrote:
> 
>> You don't need any defense -- it's no secret that mpl is
>> under-documented.  If you know how to look, the information is usually
>> there, but the trick is knowing how to look
>>
>> In [3]: l, = plot([1,2,3])
>>
>> In [4]: setp(l)
> 
> Ah, thanks for that reminder!  That's useful to know/re-know.
> 
>> This reminds me -- of late I've been wishing for a grep-like feature
>> in ipython
>>
>>   In [2]: setp(l) | grep dash
>>
>> to see just the output of setp that matches "dash".  In your case, you
>> would have seen
>>
>>     dash_capstyle: ['butt' | 'round' | 'projecting']
>>     dash_joinstyle: ['miter' | 'round' | 'bevel']
>>     dashes: sequence of on/off ink in points
>>
>> suggesting that you can not only configure the dash style, but the
>> dash cap and join style as well :-)
>>
>> Of course, I could add this functionality to setp but it would be more
>> generally useful to have it in ipython.
>>
>> The use case I had in mind today was in history, when I had a bunch of
>> commands I wanted to grep through
>>
>>   In [1000]: history | grep xxx
> 
> Yes, I also have wanted something like this.  The problem is that many
> utilities don't return anything, they just print to stdout (setp is
> one such tool).  Which means that we'd need to capture all of stdout
> and have it available for further processing always, in a non-blocking
> way (so typing 'ls' doesn't make you wait forever before printing).
> This is really pushing ipython far into the shell territory, albeit in
> a manner that would be very useful.  I'll forward this to the
> ipython-dev list, to see if Ville and Walter (the brains behind the
> fancy ipipe) want to pick this ball up and run with it.  I'm now
> pretty much only working with Brian on the new branch.

I've tried it with Robert's Redirector and the following ipipe Table:

from IPython.Extensions import ipipe

class iprint(ipipe.Table):
    def __init__(self, cmd):
        self.cmd = cmd

    def __iter__(self):
        redir = Redirector()
        redir.start()
        globals = ipipe.getglobals(None)
        exec self.cmd in {}, globals
        output = redir.stop()
        for line in output.splitlines():
            yield line

Fiddling with stdout like Redirector does seems to completely mess up
curses (doing a
   iprint("for i in xrange(10): print i") | ibrowse
gives me an
   error: nocbreak() returned ERR
exception

Would it be enough to redirect stdout on the Python level (i.e. replace
sys.stdout)?

The following works without any problems.

class iprint(ipipe.Table):
    def __init__(self, cmd):
        self.cmd = cmd

    def __iter__(self):
        oldstdout = sys.stdout
        try:
            sys.stdout = cStringIO.StringIO()
            globals = ipipe.getglobals(None)
            exec self.cmd in {}, globals
            output = sys.stdout.getvalue()
        finally:
            sys.stdout = oldstdout

        for line in output.splitlines():
            yield line

Of course
   iprint("_ip.magic('history')") | ifilter("'import' in _")
doesn't look as simple as
   %history | grep import

But currently ipipe is implemented as a display hook, so the input must
be a valid Python expression.

> Incidentally, this would bring ipython much closer to Microsoft's
> Monad shell model:
> 
>     http://arstechnica.com/guides/other/msh.ars
> 
> Ever since that review came out, I've thought that python/ipython
> already has 90% of those tools, save a proper (but better) pipe-like
> model for chaining object results.  With a bit of time investment,
> this could certainly be done.

Servus,
   Walter