From fperez.net at gmail.com  Wed Jul 12 02:17:24 2006
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 12 Jul 2006 00:17:24 -0600
Subject: [IPython-dev] Fwd: [Matplotlib-users] Improved dashing for black
	and white plots?
In-Reply-To: <db6b5ecc0607112311l7447b159md46e679ccd0ca924@mail.gmail.com>
References: <db6b5ecc0607101742k65223fafw5182ab8d7fd155c@mail.gmail.com>
	<878xn0sybp.fsf@peds-pc311.bsd.uchicago.edu>
	<db6b5ecc0607111753k7e76ef32j28af7b36e99b234a@mail.gmail.com>
	<87y7uzpnsn.fsf@peds-pc311.bsd.uchicago.edu>
	<db6b5ecc0607112311l7447b159md46e679ccd0ca924@mail.gmail.com>
Message-ID: <db6b5ecc0607112317i6b9d9abar8ddac465763fe3f8@mail.gmail.com>

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:
     def __init__(self, fd=STDOUT):
         self.fd = fd
         self.started = False

     def start(self):
         if not self.started:
             self.oldhandle = os.dup(self.fd)
             self.piper, self.pipew = os.pipe()
             os.dup2(self.pipew, self.fd)
             os.close(self.pipew)

             self.started = True

     def flush(self):
         if self.fd == STDOUT:
             sys.stdout.flush()
         elif self.fd == STDERR:
             sys.stderr.flush()

     def stop(self):
         if self.started:
             self.flush()
             os.dup2(self.oldhandle, self.fd)
             os.close(self.oldhandle)
             f = os.fdopen(self.piper, 'r')
             output = f.read()
             f.close()

             self.started = False
             return output
         else:
             return None

---------- 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.

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.

Cheers,

f


From walter at livinglogic.de  Wed Jul 12 13:02:55 2006
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Wed, 12 Jul 2006 19:02:55 +0200
Subject: [IPython-dev] Fwd: [Matplotlib-users] Improved dashing for
 black and white plots?
In-Reply-To: <db6b5ecc0607112317i6b9d9abar8ddac465763fe3f8@mail.gmail.com>
References: <db6b5ecc0607101742k65223fafw5182ab8d7fd155c@mail.gmail.com>	<878xn0sybp.fsf@peds-pc311.bsd.uchicago.edu>	<db6b5ecc0607111753k7e76ef32j28af7b36e99b234a@mail.gmail.com>	<87y7uzpnsn.fsf@peds-pc311.bsd.uchicago.edu>	<db6b5ecc0607112311l7447b159md46e679ccd0ca924@mail.gmail.com>
	<db6b5ecc0607112317i6b9d9abar8ddac465763fe3f8@mail.gmail.com>
Message-ID: <44B52B3F.7010004@livinglogic.de>

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


From walter at livinglogic.de  Wed Jul 12 13:37:16 2006
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Wed, 12 Jul 2006 19:37:16 +0200
Subject: [IPython-dev] Fwd: [Matplotlib-users] Improved dashing for
 black and white plots?
In-Reply-To: <db6b5ecc0607112317i6b9d9abar8ddac465763fe3f8@mail.gmail.com>
References: <db6b5ecc0607101742k65223fafw5182ab8d7fd155c@mail.gmail.com>	<878xn0sybp.fsf@peds-pc311.bsd.uchicago.edu>	<db6b5ecc0607111753k7e76ef32j28af7b36e99b234a@mail.gmail.com>	<87y7uzpnsn.fsf@peds-pc311.bsd.uchicago.edu>	<db6b5ecc0607112311l7447b159md46e679ccd0ca924@mail.gmail.com>
	<db6b5ecc0607112317i6b9d9abar8ddac465763fe3f8@mail.gmail.com>
Message-ID: <44B5334C.6070500@livinglogic.de>

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.

BTW, here is a version of history as a ipipe table:
------------------------
from IPython import ipapi

from IPython.Extensions import ipipe

class ihistory(ipipe.Table):
    def __init__(self, raw=False):
        self.raw = raw

    def __iter__(self):
        api = ipapi.get()
        if self.raw:
            return iter(api.IP.input_hist_raw)
        else:
            return iter(api.IP.input_hist)
------------------------

This allows stuff like

ihistory | ifilter("'import' in _")
ihistory[42]
ihistory(True) | isort

Would it make sense to put something like this into ipipe?


An while we're at it, how about an igrep:

class igrep(ipipe.Pipe):
    def __init__(self, expr):
        self.expr = re.compile(expr)

    def __xiter__(self, mode):
        for item in ipipe.xiter(self.input, mode):
            if self.expr.search(item) is not None:
                yield item

with this you can do:

ihistory | igrep("import")

Servus,
   Walter


From vivainio at gmail.com  Thu Jul 13 12:03:51 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Thu, 13 Jul 2006 19:03:51 +0300
Subject: [IPython-dev] Fwd: [Matplotlib-users] Improved dashing for
	black and white plots?
In-Reply-To: <44B5334C.6070500@livinglogic.de>
References: <db6b5ecc0607101742k65223fafw5182ab8d7fd155c@mail.gmail.com>
	<878xn0sybp.fsf@peds-pc311.bsd.uchicago.edu>
	<db6b5ecc0607111753k7e76ef32j28af7b36e99b234a@mail.gmail.com>
	<87y7uzpnsn.fsf@peds-pc311.bsd.uchicago.edu>
	<db6b5ecc0607112311l7447b159md46e679ccd0ca924@mail.gmail.com>
	<db6b5ecc0607112317i6b9d9abar8ddac465763fe3f8@mail.gmail.com>
	<44B5334C.6070500@livinglogic.de>
Message-ID: <46cb515a0607130903y12296bdds54c6bdd1b3ebff38@mail.gmail.com>

> 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.

-- 
Ville Vainio - vivainio.googlepages.com
vainio.blogspot.com - g[mail | talk]='vivainio'


From fperez.net at gmail.com  Thu Jul 13 12:20:19 2006
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 13 Jul 2006 10:20:19 -0600
Subject: [IPython-dev] Fwd: [Matplotlib-users] Improved dashing for
	black and white plots?
In-Reply-To: <46cb515a0607130903y12296bdds54c6bdd1b3ebff38@mail.gmail.com>
References: <db6b5ecc0607101742k65223fafw5182ab8d7fd155c@mail.gmail.com>
	<878xn0sybp.fsf@peds-pc311.bsd.uchicago.edu>
	<db6b5ecc0607111753k7e76ef32j28af7b36e99b234a@mail.gmail.com>
	<87y7uzpnsn.fsf@peds-pc311.bsd.uchicago.edu>
	<db6b5ecc0607112311l7447b159md46e679ccd0ca924@mail.gmail.com>
	<db6b5ecc0607112317i6b9d9abar8ddac465763fe3f8@mail.gmail.com>
	<44B5334C.6070500@livinglogic.de>
	<46cb515a0607130903y12296bdds54c6bdd1b3ebff38@mail.gmail.com>
Message-ID: <db6b5ecc0607130920t6a7bff92s609291d381535a63@mail.gmail.com>

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, but to consume them in
full if they are just going to be printed as output.  This can be
achieved by ensuring that their __repr__ (invoked at display time)
consumes them completely before rendering them.

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 :)

best,

f


From walter at livinglogic.de  Thu Jul 13 12:35:11 2006
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Thu, 13 Jul 2006 18:35:11 +0200
Subject: [IPython-dev] Fwd: [Matplotlib-users] Improved dashing for
 black and white plots?
In-Reply-To: <46cb515a0607130903y12296bdds54c6bdd1b3ebff38@mail.gmail.com>
References: <db6b5ecc0607101742k65223fafw5182ab8d7fd155c@mail.gmail.com>	
	<878xn0sybp.fsf@peds-pc311.bsd.uchicago.edu>	
	<db6b5ecc0607111753k7e76ef32j28af7b36e99b234a@mail.gmail.com>	
	<87y7uzpnsn.fsf@peds-pc311.bsd.uchicago.edu>	
	<db6b5ecc0607112311l7447b159md46e679ccd0ca924@mail.gmail.com>	
	<db6b5ecc0607112317i6b9d9abar8ddac465763fe3f8@mail.gmail.com>	
	<44B5334C.6070500@livinglogic.de>
	<46cb515a0607130903y12296bdds54c6bdd1b3ebff38@mail.gmail.com>
Message-ID: <44B6763F.1030601@livinglogic.de>

Ville Vainio 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.

This would mean that the ipipe displayhook must always be activated.
Furthermore the default display when curses isn't available shouldn't be
idump, but something that output the row right away.

Servus,
   Walter



From walter at livinglogic.de  Thu Jul 13 12:57:04 2006
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Thu, 13 Jul 2006 18:57:04 +0200
Subject: [IPython-dev] Fwd: [Matplotlib-users] Improved dashing for
 black and white plots?
In-Reply-To: <db6b5ecc0607130920t6a7bff92s609291d381535a63@mail.gmail.com>
References: <db6b5ecc0607101742k65223fafw5182ab8d7fd155c@mail.gmail.com>	
	<878xn0sybp.fsf@peds-pc311.bsd.uchicago.edu>	
	<db6b5ecc0607111753k7e76ef32j28af7b36e99b234a@mail.gmail.com>	
	<87y7uzpnsn.fsf@peds-pc311.bsd.uchicago.edu>	
	<db6b5ecc0607112311l7447b159md46e679ccd0ca924@mail.gmail.com>	
	<db6b5ecc0607112317i6b9d9abar8ddac465763fe3f8@mail.gmail.com>	
	<44B5334C.6070500@livinglogic.de>	
	<46cb515a0607130903y12296bdds54c6bdd1b3ebff38@mail.gmail.com>
	<db6b5ecc0607130920t6a7bff92s609291d381535a63@mail.gmail.com>
Message-ID: <44B67B60.4020304@livinglogic.de>

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


From vivainio at gmail.com  Thu Jul 13 14:01:20 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Thu, 13 Jul 2006 21:01:20 +0300
Subject: [IPython-dev] Fwd: [Matplotlib-users] Improved dashing for
	black and white plots?
In-Reply-To: <44B67B60.4020304@livinglogic.de>
References: <db6b5ecc0607101742k65223fafw5182ab8d7fd155c@mail.gmail.com>
	<878xn0sybp.fsf@peds-pc311.bsd.uchicago.edu>
	<db6b5ecc0607111753k7e76ef32j28af7b36e99b234a@mail.gmail.com>
	<87y7uzpnsn.fsf@peds-pc311.bsd.uchicago.edu>
	<db6b5ecc0607112311l7447b159md46e679ccd0ca924@mail.gmail.com>
	<db6b5ecc0607112317i6b9d9abar8ddac465763fe3f8@mail.gmail.com>
	<44B5334C.6070500@livinglogic.de>
	<46cb515a0607130903y12296bdds54c6bdd1b3ebff38@mail.gmail.com>
	<db6b5ecc0607130920t6a7bff92s609291d381535a63@mail.gmail.com>
	<44B67B60.4020304@livinglogic.de>
Message-ID: <46cb515a0607131101r1bc2199doe8eb1b4b8a2f3196@mail.gmail.com>

On 7/13/06, Walter D?rwald <walter at livinglogic.de> wrote:

> 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?

Can't you just use normal os.popen4 to get both stdout and stderr (and
thus avoid the risk of screwing the screen?)

> 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).

It shouldn't, normally. We could have an input prefilter for turning
the first part of the pipeline to ix(cmd) but the rest of the pipeline
should be explicit ipipe function invocations (i.e. normal python).

What should the input prefilter look for? Perhaps two |'s at the start
of the line, e.g.

|| ls *.exe | igrep("foo")

Would be translated to

ix("ls *.exe")  | igrep("foo")

-- 
Ville Vainio - vivainio.googlepages.com
vainio.blogspot.com - g[mail | talk]='vivainio'


From walter at livinglogic.de  Fri Jul 14 06:35:32 2006
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Fri, 14 Jul 2006 12:35:32 +0200
Subject: [IPython-dev] Fwd: [Matplotlib-users] Improved dashing for
 black and white plots?
In-Reply-To: <46cb515a0607131101r1bc2199doe8eb1b4b8a2f3196@mail.gmail.com>
References: <db6b5ecc0607101742k65223fafw5182ab8d7fd155c@mail.gmail.com>	
	<878xn0sybp.fsf@peds-pc311.bsd.uchicago.edu>	
	<db6b5ecc0607111753k7e76ef32j28af7b36e99b234a@mail.gmail.com>	
	<87y7uzpnsn.fsf@peds-pc311.bsd.uchicago.edu>	
	<db6b5ecc0607112311l7447b159md46e679ccd0ca924@mail.gmail.com>	
	<db6b5ecc0607112317i6b9d9abar8ddac465763fe3f8@mail.gmail.com>	
	<44B5334C.6070500@livinglogic.de>	
	<46cb515a0607130903y12296bdds54c6bdd1b3ebff38@mail.gmail.com>	
	<db6b5ecc0607130920t6a7bff92s609291d381535a63@mail.gmail.com>	
	<44B67B60.4020304@livinglogic.de>
	<46cb515a0607131101r1bc2199doe8eb1b4b8a2f3196@mail.gmail.com>
Message-ID: <44B77374.3010606@livinglogic.de>

Ville Vainio wrote:
> On 7/13/06, Walter D?rwald <walter at livinglogic.de> wrote:
> 
>> 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?
> 
> Can't you just use normal os.popen4 to get both stdout and stderr (and
> thus avoid the risk of screwing the screen?)

I'll give this a try.

Another problem is when output is canceled while the external program is
still running. I'm using a pipe.close() in the __del__() method, but
that doesn't work reliably. I guess Python 2.5 would solve this problem
with try:finally: support in generators.

>> 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).
> 
> It shouldn't, normally. We could have an input prefilter for turning
> the first part of the pipeline to ix(cmd) but the rest of the pipeline
> should be explicit ipipe function invocations (i.e. normal python).

How is ! handled?

> What should the input prefilter look for? Perhaps two |'s at the start
> of the line, e.g.
> 
> || ls *.exe | igrep("foo")
> 
> Would be translated to
> 
> ix("ls *.exe")  | igrep("foo")

It would be great if shell expressions could be used in the middle of a
pipeline. Maybe we should use backticks for that?

(random.randint(0, 255) for i in xrange(256)) | isort | `uniq`

Servus,
   Walter



From vivainio at gmail.com  Fri Jul 14 06:52:25 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Fri, 14 Jul 2006 13:52:25 +0300
Subject: [IPython-dev] Fwd: [Matplotlib-users] Improved dashing for
	black and white plots?
In-Reply-To: <44B77374.3010606@livinglogic.de>
References: <db6b5ecc0607101742k65223fafw5182ab8d7fd155c@mail.gmail.com>
	<87y7uzpnsn.fsf@peds-pc311.bsd.uchicago.edu>
	<db6b5ecc0607112311l7447b159md46e679ccd0ca924@mail.gmail.com>
	<db6b5ecc0607112317i6b9d9abar8ddac465763fe3f8@mail.gmail.com>
	<44B5334C.6070500@livinglogic.de>
	<46cb515a0607130903y12296bdds54c6bdd1b3ebff38@mail.gmail.com>
	<db6b5ecc0607130920t6a7bff92s609291d381535a63@mail.gmail.com>
	<44B67B60.4020304@livinglogic.de>
	<46cb515a0607131101r1bc2199doe8eb1b4b8a2f3196@mail.gmail.com>
	<44B77374.3010606@livinglogic.de>
Message-ID: <46cb515a0607140352j3c3e2bbbnacc2fc514a208f23@mail.gmail.com>

On 7/14/06, Walter D?rwald <walter at livinglogic.de> wrote:

> > It shouldn't, normally. We could have an input prefilter for turning
> > the first part of the pipeline to ix(cmd) but the rest of the pipeline
> > should be explicit ipipe function invocations (i.e. normal python).
>
> How is ! handled?

It gets turned into _ip.system(cmd) python statement, which of course
executes the whole line in cell. See Extensions/ext_rescapture.py on
how to add a new input_prefilter hook.

> It would be great if shell expressions could be used in the middle of a
> pipeline. Maybe we should use backticks for that?
>
> (random.randint(0, 255) for i in xrange(256)) | isort | `uniq`

It would obviously be great in pipeline expressions (started with ||,
i.e. something starting with a system command execution) but less
obvious in arbitrary command lines like the one in your example (how
do we recognize that this is a pipeline and therefore backticks need
to be handled as system commands? )

Perhaps we should have a prefilter that considers "series of elements
separated by | where at least one is in backticks and that don't start
with a valid system command" as a pipeline where backticks get turned
to ix()?

It would make

`cat hi.txt` | isort

work but

cat hi.txt | isort

would fail (because cat is a system command and passed through normal
_ip.system() mechanism, which should still be the case).

-- 
Ville Vainio - vivainio.googlepages.com
vainio.blogspot.com - g[mail | talk]='vivainio'


From fperez.net at gmail.com  Fri Jul 14 12:15:50 2006
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 14 Jul 2006 10:15:50 -0600
Subject: [IPython-dev] Improved piping functionality (was: ...dashing for
	black and white...)
Message-ID: <db6b5ecc0607140915o20189e88yb8e2528a9feb52ed@mail.gmail.com>

[ Renaming thread so the subject is more informative ]

> Perhaps we should have a prefilter that considers "series of elements
> separated by | where at least one is in backticks and that don't start
> with a valid system command" as a pipeline where backticks get turned
> to ix()?

I'd suggest trying to keep more inline with the python language, even
at the cost of some syntactic convenience.  My experience is that
otherwise, these rather obscure combinations of special syntax simply
won't be used by absolutely anyone outside 2 or 3 diehards.

One of python's greatest strengths is that its working set 'fits in
cache' very easily (cf. Perl or C++).  I think it's OK that ipython
extends the basic language /somewhat/, but we should try to do so with
a minimal set of easy to remember, reusable ideas.

I know this is not easy, especially because you are running into the
design of the language itself in areas where, for this kind of usage,
it may be less than ideal.  But that's what makes the problem
interesting :)

Just some thoughts...

f


From walter at livinglogic.de  Fri Jul 14 12:33:00 2006
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Fri, 14 Jul 2006 18:33:00 +0200
Subject: [IPython-dev] Fwd: [Matplotlib-users] Improved dashing for
 black and white plots?
In-Reply-To: <46cb515a0607140352j3c3e2bbbnacc2fc514a208f23@mail.gmail.com>
References: <db6b5ecc0607101742k65223fafw5182ab8d7fd155c@mail.gmail.com>	
	<87y7uzpnsn.fsf@peds-pc311.bsd.uchicago.edu>	
	<db6b5ecc0607112311l7447b159md46e679ccd0ca924@mail.gmail.com>	
	<db6b5ecc0607112317i6b9d9abar8ddac465763fe3f8@mail.gmail.com>	
	<44B5334C.6070500@livinglogic.de>	
	<46cb515a0607130903y12296bdds54c6bdd1b3ebff38@mail.gmail.com>	
	<db6b5ecc0607130920t6a7bff92s609291d381535a63@mail.gmail.com>	
	<44B67B60.4020304@livinglogic.de>	
	<46cb515a0607131101r1bc2199doe8eb1b4b8a2f3196@mail.gmail.com>	
	<44B77374.3010606@livinglogic.de>
	<46cb515a0607140352j3c3e2bbbnacc2fc514a208f23@mail.gmail.com>
Message-ID: <44B7C73C.90604@livinglogic.de>

Ville Vainio wrote:

> On 7/14/06, Walter D?rwald <walter at livinglogic.de> wrote:
> 
>> > It shouldn't, normally. We could have an input prefilter for turning
>> > the first part of the pipeline to ix(cmd) but the rest of the pipeline
>> > should be explicit ipipe function invocations (i.e. normal python).
>>
>> How is ! handled?
> 
> It gets turned into _ip.system(cmd) python statement, which of course
> executes the whole line in cell. See Extensions/ext_rescapture.py on
> how to add a new input_prefilter hook.

Thanks for the hint. It would be simple enough to add a handler for
"`(?P<cmd>.*)`". I think I'll play around with this over the weekend.

>> It would be great if shell expressions could be used in the middle of a
>> pipeline. Maybe we should use backticks for that?
>>
>> (random.randint(0, 255) for i in xrange(256)) | isort | `uniq`
> 
> It would obviously be great in pipeline expressions (started with ||,
> i.e. something starting with a system command execution) but less
> obvious in arbitrary command lines like the one in your example (how
> do we recognize that this is a pipeline and therefore backticks need
> to be handled as system commands? )

I would have suggested simply taking over the backticks, i.e. something
with backticks *always* gets replaced. But this might be too radical, so
we need other delimiters that are unused in normal Python code.

> Perhaps we should have a prefilter that considers "series of elements
> separated by | where at least one is in backticks and that don't start
> with a valid system command" as a pipeline where backticks get turned
> to ix()?

If all backticks would get turned into ix() it would automatically be a
pipeline expression (as it contains an ipipe table).

> It would make
> 
> `cat hi.txt` | isort
> 
> work but
> 
> cat hi.txt | isort
> 
> would fail (because cat is a system command and passed through normal
> _ip.system() mechanism, which should still be the case).

Servus,
   Walter


From vivainio at gmail.com  Fri Jul 14 12:35:16 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Fri, 14 Jul 2006 19:35:16 +0300
Subject: [IPython-dev] Improved piping functionality (was: ...dashing
	for black and white...)
In-Reply-To: <db6b5ecc0607140915o20189e88yb8e2528a9feb52ed@mail.gmail.com>
References: <db6b5ecc0607140915o20189e88yb8e2528a9feb52ed@mail.gmail.com>
Message-ID: <46cb515a0607140935m72f54596iff195c3b3bf3b178@mail.gmail.com>

On 7/14/06, Fernando Perez <fperez.net at gmail.com> wrote:

> I'd suggest trying to keep more inline with the python language, even
> at the cost of some syntactic convenience.  My experience is that
> otherwise, these rather obscure combinations of special syntax simply
> won't be used by absolutely anyone outside 2 or 3 diehards.

I see this more as a shell-like feature, and the only thing to
remember is "backticks are a shorthand for ix(cmd)". It's not too bad.

-- 
Ville Vainio - vivainio.googlepages.com
vainio.blogspot.com - g[mail | talk]='vivainio'


From walter at livinglogic.de  Fri Jul 14 12:39:46 2006
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Fri, 14 Jul 2006 18:39:46 +0200
Subject: [IPython-dev] Improved piping functionality (was: ...dashing
 for black and white...)
In-Reply-To: <db6b5ecc0607140915o20189e88yb8e2528a9feb52ed@mail.gmail.com>
References: <db6b5ecc0607140915o20189e88yb8e2528a9feb52ed@mail.gmail.com>
Message-ID: <44B7C8D2.8070106@livinglogic.de>

Fernando Perez wrote:

> [ Renaming thread so the subject is more informative ]
> 
>> Perhaps we should have a prefilter that considers "series of elements
>> separated by | where at least one is in backticks and that don't start
>> with a valid system command" as a pipeline where backticks get turned
>> to ix()?
> 
> I'd suggest trying to keep more inline with the python language, even
> at the cost of some syntactic convenience.  My experience is that
> otherwise, these rather obscure combinations of special syntax simply
> won't be used by absolutely anyone outside 2 or 3 diehards.

I can live with ix("foo") instead of `foo` (that's why I choose a short
class name).

To be able to use ix() inside a pipeline expression, there's still some
work to be done anyway: If the ix() object has an input pipe, the
strings from the input pipe must be written to the pipe's stdin.

> One of python's greatest strengths is that its working set 'fits in
> cache' very easily (cf. Perl or C++).  I think it's OK that ipython
> extends the basic language /somewhat/, but we should try to do so with
> a minimal set of easy to remember, reusable ideas.
> 
> I know this is not easy, especially because you are running into the
> design of the language itself in areas where, for this kind of usage,
> it may be less than ideal.  But that's what makes the problem
> interesting :)

So far ipipe doesn't use a prefilter hook. If ipipe ever grows one, the
basic functionality should stay usable, i.e. it should still be possible
to input the pipe expression as plain Python syntax.

Servus,
   Walter


From walter at livinglogic.de  Fri Jul 14 12:48:16 2006
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Fri, 14 Jul 2006 18:48:16 +0200
Subject: [IPython-dev] Improved piping functionality (was: ...dashing
 for black and white...)
In-Reply-To: <46cb515a0607140935m72f54596iff195c3b3bf3b178@mail.gmail.com>
References: <db6b5ecc0607140915o20189e88yb8e2528a9feb52ed@mail.gmail.com>
	<46cb515a0607140935m72f54596iff195c3b3bf3b178@mail.gmail.com>
Message-ID: <44B7CAD0.3000401@livinglogic.de>

Ville Vainio wrote:
> On 7/14/06, Fernando Perez <fperez.net at gmail.com> wrote:
> 
>> I'd suggest trying to keep more inline with the python language, even
>> at the cost of some syntactic convenience.  My experience is that
>> otherwise, these rather obscure combinations of special syntax simply
>> won't be used by absolutely anyone outside 2 or 3 diehards.
> 
> I see this more as a shell-like feature, and the only thing to
> remember is "backticks are a shorthand for ix(cmd)". It's not too bad.

I'll give it a try, and we'll see how this works out.

BTW, about your proposal to let magic commands return ipipe tables: I
tried it with the history and couldn't get it to work. Either the output
of magic commands doesn't go through the display hooks, or we have a
bootstrapping problem.

A simplifying solution would be to use the ipipe display functionality
for everything not just for tables. I.e. instead of being able to switch
between pretty printed output and normal output the options would be:
* normal
* pretty print
* idump
* ibrowse
The default could be the same as for 0.7.2.

Of course for something that isn't iterable we'd need a fallback to
normal output.

Servus,
   Walter


From vivainio at gmail.com  Fri Jul 14 12:55:56 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Fri, 14 Jul 2006 19:55:56 +0300
Subject: [IPython-dev] Improved piping functionality (was: ...dashing
	for black and white...)
In-Reply-To: <44B7CAD0.3000401@livinglogic.de>
References: <db6b5ecc0607140915o20189e88yb8e2528a9feb52ed@mail.gmail.com>
	<46cb515a0607140935m72f54596iff195c3b3bf3b178@mail.gmail.com>
	<44B7CAD0.3000401@livinglogic.de>
Message-ID: <46cb515a0607140955x41f5d069jc5c81bb27592e03c@mail.gmail.com>

On 7/14/06, Walter D?rwald <walter at livinglogic.de> wrote:

> BTW, about your proposal to let magic commands return ipipe tables: I
> tried it with the history and couldn't get it to work. Either the output
> of magic commands doesn't go through the display hooks, or we have a
> bootstrapping problem.

What does _ip.magic("history") return in your case? That certainly
will go through the display hook...

> A simplifying solution would be to use the ipipe display functionality
> for everything not just for tables. I.e. instead of being able to switch

Sounds a little bit wild, considering that it would eat up generators
if enabled...

-- 
Ville Vainio - vivainio.googlepages.com
vainio.blogspot.com - g[mail | talk]='vivainio'


From walter at livinglogic.de  Fri Jul 14 13:13:32 2006
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Fri, 14 Jul 2006 19:13:32 +0200
Subject: [IPython-dev] Improved piping functionality (was: ...dashing
 for black and white...)
In-Reply-To: <46cb515a0607140955x41f5d069jc5c81bb27592e03c@mail.gmail.com>
References: <db6b5ecc0607140915o20189e88yb8e2528a9feb52ed@mail.gmail.com>	
	<46cb515a0607140935m72f54596iff195c3b3bf3b178@mail.gmail.com>	
	<44B7CAD0.3000401@livinglogic.de>
	<46cb515a0607140955x41f5d069jc5c81bb27592e03c@mail.gmail.com>
Message-ID: <44B7D0BC.5020400@livinglogic.de>

Ville Vainio wrote:

> On 7/14/06, Walter D?rwald <walter at livinglogic.de> wrote:
> 
>> BTW, about your proposal to let magic commands return ipipe tables: I
>> tried it with the history and couldn't get it to work. Either the output
>> of magic commands doesn't go through the display hooks, or we have a
>> bootstrapping problem.
> 
> What does _ip.magic("history") return in your case? That certainly
> will go through the display hook...

In [1]: _ip.magic("history")
Out[1]: ['_ip.magic("history")\n']

The strange thing is that with the patched Magic.py none of the ipipe
tables work any more. If I remove all my changes from Magic.py except
the import (from IPython.Extensions import ipipe) it's still broken.
Moving the import into magic_history() fixes the problem.

>> A simplifying solution would be to use the ipipe display functionality
>> for everything not just for tables. I.e. instead of being able to switch
> 
> Sounds a little bit wild, considering that it would eat up generators
> if enabled...

You're right, I think this kill it. Another option would be to never
output anything via an ipipe display unless it's explicitely requested.

With a prefilter hook this could be shortened to one character:
   ils | isort^
would get mapped to
   ils | isort | ipipe.defaultdisplay()

Servus,
   Walter


From walter at livinglogic.de  Fri Jul 14 13:31:56 2006
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Fri, 14 Jul 2006 19:31:56 +0200
Subject: [IPython-dev] Improved piping functionality (was: ...dashing
 for black and white...)
In-Reply-To: <44B77374.3010606@livinglogic.de>
References: <db6b5ecc0607101742k65223fafw5182ab8d7fd155c@mail.gmail.com>		<878xn0sybp.fsf@peds-pc311.bsd.uchicago.edu>		<db6b5ecc0607111753k7e76ef32j28af7b36e99b234a@mail.gmail.com>		<87y7uzpnsn.fsf@peds-pc311.bsd.uchicago.edu>		<db6b5ecc0607112311l7447b159md46e679ccd0ca924@mail.gmail.com>		<db6b5ecc0607112317i6b9d9abar8ddac465763fe3f8@mail.gmail.com>		<44B5334C.6070500@livinglogic.de>		<46cb515a0607130903y12296bdds54c6bdd1b3ebff38@mail.gmail.com>		<db6b5ecc0607130920t6a7bff92s609291d381535a63@mail.gmail.com>		<44B67B60.4020304@livinglogic.de>	<46cb515a0607131101r1bc2199doe8eb1b4b8a2f3196@mail.gmail.com>
	<44B77374.3010606@livinglogic.de>
Message-ID: <44B7D50C.1030906@livinglogic.de>

Walter D?rwald wrote:
> Ville Vainio wrote:
>> On 7/13/06, Walter D?rwald <walter at livinglogic.de> wrote:
>>
>>> 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?
>> Can't you just use normal os.popen4 to get both stdout and stderr (and
>> thus avoid the risk of screwing the screen?)
> 
> I'll give this a try.

I just checked in a patch that changes ix() to use os.popen4(). Now you
can do e.g.:
   ix("find /") | ifile
This seems to be pretty fast. Using the goto command to jump to row
10000 is practically instant. (Press "g" enter "10000" and press RETURN).

Servus,
   Walter




From fperez.net at gmail.com  Sun Jul 16 13:43:40 2006
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 16 Jul 2006 11:43:40 -0600
Subject: [IPython-dev] Fwd: [Enthought-dev] "bell" sounds for "tab"
	character in enthon 0.97
In-Reply-To: <1153020138.19075@mail.enthought.com>
References: <44B6543D.6040607@enthought.com>
	<1153020138.19075@mail.enthought.com>
Message-ID: <db6b5ecc0607161043s256d08ay9abedcf5a1794702@mail.gmail.com>

Hey guys,

could one of you who uses windows and knows about our pyreadline (esp.
Jorgen) have a look at this?  The python Enthought edition is readying
for a 1.0 release and they ship ipython/pyreadline, and they're having
problems.  It would be nice if we could sort this out before 1.0.

Thanks,

f

---------- Forwarded message ----------
From: Peter Wang <pwang at enthought.com>
Date: Jul 15, 2006 9:22 PM
Subject: Re: [Enthought-dev] "bell" sounds for "tab" character in enthon 0.97
To: enthought-dev at enthought.com


bryce hendrix wrote ..
> Enthon 1.0.0 switched from the readline package to pyreadline, so some
> of the readline wierdness has either gone away, or has been traded for
> new python wierdness. I can test it out when I roll out Beta 4 this
> afternoon.

Some of the new weirdness in 1.0.0b4:
On windows XP on my laptop, when I hit tab, the cursor advances only a
single space; however, when I start typing, the characters I type
appear at a position 3 spaces after the cursor position.  Needless to
say, this is extremely disorienting, especially since the cursor
starts advancing over the previously typed text (assuming I've typed
more than 3 letters).


-Peter


_______________________________________________
Enthought-dev mailing list
Enthought-dev at mail.enthought.com
https://mail.enthought.com/mailman/listinfo/enthought-dev


From jorgen.stenarson at bostream.nu  Mon Jul 17 16:54:15 2006
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Mon, 17 Jul 2006 22:54:15 +0200
Subject: [IPython-dev] Fwd: [Enthought-dev] "bell" sounds for
 "tab"	character in enthon 0.97
In-Reply-To: <db6b5ecc0607161043s256d08ay9abedcf5a1794702@mail.gmail.com>
References: <44B6543D.6040607@enthought.com>	<1153020138.19075@mail.enthought.com>
	<db6b5ecc0607161043s256d08ay9abedcf5a1794702@mail.gmail.com>
Message-ID: <44BBF8F7.1050702@bostream.nu>

Hi,

I hope this reaches enthought-dev as well (I don't subscribe so please 
cc any response directly to me).
I will look into to this tomorrow. Could someone provide information on 
what version of pyreadline was used is it the released 1.3 version or 
was it taken from svn (if so which revision?). Is it possible to install 
enthon without clobbering my normal python install i.e. file 
associations etc.

/J?rgen

Fernando Perez skrev:
> Hey guys,
> 
> could one of you who uses windows and knows about our pyreadline (esp.
> Jorgen) have a look at this?  The python Enthought edition is readying
> for a 1.0 release and they ship ipython/pyreadline, and they're having
> problems.  It would be nice if we could sort this out before 1.0.
> 
> Thanks,
> 
> f
> 
> ---------- Forwarded message ----------
> From: Peter Wang <pwang at enthought.com>
> Date: Jul 15, 2006 9:22 PM
> Subject: Re: [Enthought-dev] "bell" sounds for "tab" character in enthon 0.97
> To: enthought-dev at enthought.com
> 
> 
> bryce hendrix wrote ..
>> Enthon 1.0.0 switched from the readline package to pyreadline, so some
>> of the readline wierdness has either gone away, or has been traded for
>> new python wierdness. I can test it out when I roll out Beta 4 this
>> afternoon.
> 
> Some of the new weirdness in 1.0.0b4:
> On windows XP on my laptop, when I hit tab, the cursor advances only a
> single space; however, when I start typing, the characters I type
> appear at a position 3 spaces after the cursor position.  Needless to
> say, this is extremely disorienting, especially since the cursor
> starts advancing over the previously typed text (assuming I've typed
> more than 3 letters).
> 
> 
> -Peter
> 
> 
> _______________________________________________
> Enthought-dev mailing list
> Enthought-dev at mail.enthought.com
> https://mail.enthought.com/mailman/listinfo/enthought-dev
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/ipython-dev
> 



From jorgen.stenarson at bostream.nu  Tue Jul 18 15:10:00 2006
From: jorgen.stenarson at bostream.nu (=?UTF-8?B?SsO2cmdlbiBTdGVuYXJzb24=?=)
Date: Tue, 18 Jul 2006 21:10:00 +0200
Subject: [IPython-dev] Release of pyreadline 1.3
In-Reply-To: <44B9DAC7.5000900@ukr.net>
References: <447E8698.8010808@colorado.edu>
	<447F47FB.3050203@bostream.nu>	<44866931.2080502@ukr.net>
	<44A0313F.80800@bostream.nu> <44B9DAC7.5000900@ukr.net>
Message-ID: <44BD3208.7030401@bostream.nu>

Aleander,

I could not reproduce your problems. But I have made some additional 
changes to the color handling so perhaps your problem was fixed. If not 
please let me know, it would also be useful to know your color settings 
in the windows console.

/J?rgen

Alexander Belchenko skrev:
> J?rgen Stenarson ?????:
>> Alexander Belchenko skrev:
>>> I download and install new pyreadline and test it with IPython 0.7.1.
>>> Suddenly this implementation has some undesirable effect (in compare
>>> with UNC readline): when IPython running it use settings of console for
>>> foreground color, but in the prompt it try to force to use darker color.
>>> But I don't want it! And even when I switch manually color of foreground
>>> for my console back to bright yellow (as my default when IPython
>>> started) then during multiline editing pyreadline again switch to dark
>>> yellow color.
> ...
>>
>> I have comitted a patch to svn so please try the trunk version and let 
>> me know if there are any problems.
> 
> Hmmm. There is problem with that patch.
> 
> There is no problem with LightBG color scheme but I have problems with 
> Linux color scheme (at black background).
> 
> Reproduction of problem in IPython:
> 
> import os
> os.path?
> 
> When I use your original release of pyreadline 1.3 then all docstrings 
> prints OK. See screenshot original.png.
> 
> When I install patched version of pyreadline then magic help prints as 
> black on black. See screenshot patched.png.
> 
> -- 
> Alexander
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 



From stefan at sun.ac.za  Thu Jul 20 07:03:21 2006
From: stefan at sun.ac.za (Stefan van der Walt)
Date: Thu, 20 Jul 2006 13:03:21 +0200
Subject: [IPython-dev] cpaste and history
Message-ID: <20060720110321.GH23629@mentat.za.net>

Hi all,

While using cpaste, I noticed that the readline search history does
not reflect the executed code.  I.e., if you do

In [1]: cpaste
Pasting code; enter '--' alone on the line to stop.
:    x = 1
:--
x = 1

and then type

In [2]: x =<up-arrow>

it does not complete.  Rather

In [2]:     x =<up-arrow>

does.  I played around a bit, but couldn't see an obvious way to
retrospectively change the raw_input history.  Does anyone here know
how?

While I see the logic of the current behaviour, I think it might be
more useful to put the dedented commands in the history.

Cheers
St?fan


From Fernando.Perez at colorado.edu  Mon Jul 24 02:37:44 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Mon, 24 Jul 2006 00:37:44 -0600
Subject: [IPython-dev] Multi-line history entries
In-Reply-To: <20060723223415.GA31670@pyret>
References: <20060723223415.GA31670@pyret>
Message-ID: <44C46AB8.7010303@colorado.edu>

Hi Jorgen,

Jorgen Cederlof wrote:

> Hi,
> 
> I tried subscribing to the mailing list to send this, but I didn't get
> a confirmation mail. Well, I can just as well send this to you
> instead.

Thanks for the patch.  I've forwarded it to python-dev, so the trunk 
maintainers can have a look and commit it.  They work much more with the shell 
side of things than I do these days, so they're in a better position to 
evaluate it.


> 
> I recently started using IPython, and it is a great enhancement over
> the normal Python shell. I found that the handling of multi-line
> entries could be improved, and I found some discussion on the mailing
> list about that:
> http://www.scipy.net/pipermail/ipython-dev/2005-December/000694.html . 
> Since Bash handles multi-line entries with Readline, I just used the
> same method Bash uses and came up with this:

--- ipython-0.7.2/IPython/iplib.py.orig 2006-07-23 01:45:20.000000000 +0200
+++ ipython-0.7.2/IPython/iplib.py      2006-07-23 02:48:29.000000000 +0200
@@ -1763,7 +1763,8 @@
          # push).

          #print 'push line: <%s>' % line  # dbg
-        self.autoindent_update(line)
+        for subline in line.splitlines():
+            self.autoindent_update(subline)

          self.buffer.append(line)
          more = self.runsource('\n'.join(self.buffer), self.filename)
@@ -1806,6 +1807,14 @@
          if line.strip():
              if continue_prompt:
                  self.input_hist_raw[-1] += '%s\n' % line
+                if self.has_readline: # and some config option is set?
+                    try:
+                        histlen = self.readline.get_current_history_length()
+                        newhist = self.input_hist_raw[-1].rstrip()
+                        self.readline.remove_history_item(histlen-1)
+                        self.readline.replace_history_item(histlen-2,newhist)
+                    except AttributeError:
+                        pass # re{move,place}_history_item are new in 2.4.
              else:
                  self.input_hist_raw.append('%s\n' % line)


> This works fine for me. One thing that might be improved is that
> Up-arrow moves to previous history entry instead of moving up a line
> in the current entry, just like in Bash. And because of what seems to
> be a bug in Readline a saved multi-line history entry is transformed
> to several one-line entries when the history file is read back, again
> just like in Bash. Anyway, with this change I find IPython much easier
> to use.
> 
> Regards,
> J??rgen


From vivian at vdesmedt.com  Mon Jul 24 05:44:39 2006
From: vivian at vdesmedt.com (Vivian De Smedt)
Date: Mon, 24 Jul 2006 11:44:39 +0200
Subject: [IPython-dev] Multi-line history entries
In-Reply-To: <44C46AB8.7010303@colorado.edu>
References: <20060723223415.GA31670@pyret> <44C46AB8.7010303@colorado.edu>
Message-ID: <44C49687.8090803@vdesmedt.com>

Hi J?rgen,

I'm very glad that somebody go into that direction. I'm using windows 
and the the Python version of readline (pyreadline) and your patch do 
not seems to work with this version of the readline library.

I'm not very used to linux, bach nor with the unix version of the 
readline library so I would like to know more about its functionality to 
know more about how it is supposed to work and in particular how it 
match the behavior I describe in the mail you site in your mail.

Could you give me more informations or could you point to some 
documentations I could read.

Thank again for your patch,
Kindest regards,
Vivian De Smedt.


From Fernando.Perez at colorado.edu  Mon Jul 24 20:07:02 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Mon, 24 Jul 2006 18:07:02 -0600
Subject: [IPython-dev] [Fwd: Auto-discard notification]
Message-ID: <44C560A6.3050309@colorado.edu>


-------- Original Message --------
Subject: Auto-discard notification
Date: Mon, 24 Jul 2006 19:03:19 -0500
From: ipython-dev-bounces at scipy.org
To: ipython-dev-owner at scipy.org

The attached message has been automatically discarded.
Subject:
Re: [IPython-dev] Multi-line history entries
From:
Jorgen Cederlof <jc at lysator.liu.se>
Date:
Tue, 25 Jul 2006 01:59:06 +0200
To:
Vivian De Smedt <vivian at vdesmedt.com>
CC:
IPython-dev List <ipython-dev at scipy.net>

On Mon, Jul 24, 2006 at 11:44:39 +0200, Vivian De Smedt wrote:

 >> Hi J?rgen,
 >>
 >> I'm very glad that somebody go into that direction. I'm using
 >> windows and the the Python version of readline (pyreadline) and your
 >> patch do not seems to work with this version of the readline
 >> library.
 >>
 >> I'm not very used to linux, bach nor with the unix version of the
 >> readline library so I would like to know more about its
 >> functionality to know more about how it is supposed to work and in
 >> particular how it match the behavior I describe in the mail you site
 >> in your mail.
 >>
 >> Could you give me more informations or could you point to some
 >> documentations I could read.


The approach in my patch was quite simple. The last part means that if
the current line was a continuation, then the two last entries in
readline's internal history should really be just one entry.
Therefore, remove the last entry and replace the entry before that
with the concatenation of the two entries.

To do that we need the readline.remove_history_item() and
readline.replace_history_item() functions which are new in (Unix
version of) Python 2.4. You can read the documentation at
http://docs.python.org/lib/module-readline.html . I don't know if
anything similar is available for pyreadline.

The first part of the patch is just to feed the auto-indentation code
with one line at a time when entering something that spans over
several lines, otherwise it fails to auto-indent the next line.

Anyway, the user-visible difference the patch makes is just that when
you step or search through the history, an expression that spans
several lines will be shown as a single entry spanning several lines
instead of one entry for each line. The rest of the screen will scroll
as much as needed to make place for the multi-line entry. That is
probably quite different from your suggestion. To move around in it
you can unfortunately not use up-arrow and down-arrow, since that will
just move you to another history entry.

If you ever find a way to try bash, you will find that it behaves the
same way. zsh is different, in zsh those keys move the cursor inside a
multi-line entry if possible and only move to the previous/next entry
if the cursor is at the top/bottom line. That behaviour should be much
better for a Python shell.

          J?rgen
-------------- next part --------------
An embedded message was scrubbed...
From: Jorgen Cederlof <jc at lysator.liu.se>
Subject: Re: [IPython-dev] Multi-line history entries
Date: Tue, 25 Jul 2006 01:59:06 +0200
Size: 4007
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20060724/939bc43f/attachment.eml>

From Fernando.Perez at colorado.edu  Tue Jul 25 02:13:32 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Tue, 25 Jul 2006 00:13:32 -0600
Subject: [IPython-dev] python2.5
In-Reply-To: <op.tc8dlfzw81133a@localhost>
References: <op.tc8dlfzw81133a@localhost>
Message-ID: <44C5B68C.5010808@colorado.edu>

Hi William,

[ I just whitelisted your address on ipython-{user,dev} so you don't get 
bounces again ]

William Stein wrote:
> Hi Fernando and Ville,
> 
> Have you tried Ipython with Python2.5 beta2 yet?   Since Python2.5
> is supposed to be released in "early August", it might be worth
> thinking about it.  I'm getting SAGE ready for Python 2.5, and
> I noticed that IPython is somewhat broken under Python 2.5.

Thanks for the heads-up.  No, I hadn't built 2.5 yet, but I guess it's time to 
start playing with it.  Ville is doing the real work on trunk these days, but 
I'll certainly help with this if needed, as I consider it a major priority, 
and it may require knowledge of parts of the code only I know well.  This is 
also something that I could put on the list for the scipy sprints days (are 
you going to be there for Mon/Tue?).

Cheers,

f


From Fernando.Perez at colorado.edu  Tue Jul 25 02:14:19 2006
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Tue, 25 Jul 2006 00:14:19 -0600
Subject: [IPython-dev] [Fwd: python2.5]
Message-ID: <44C5B6BB.40807@colorado.edu>

This is William's original message which got auto-discarded, and to which I 
just replied.

-------- Original Message --------
Subject: python2.5
Date: Mon, 24 Jul 2006 22:59:29 -0700
From: William Stein <wstein at gmail.com>
Reply-To: wstein at gmail.com
Organization: University of Washington
To: Fernando Perez <Fernando.Perez at colorado.edu>
CC: ipython-dev at scipy.net,        "sage-devel at lists.sourceforge.net" 
<sage-devel at lists.sourceforge.net>

Hi Fernando and Ville,

Have you tried Ipython with Python2.5 beta2 yet?   Since Python2.5
is supposed to be released in "early August", it might be worth
thinking about it.  I'm getting SAGE ready for Python 2.5, and
I noticed that IPython is somewhat broken under Python 2.5.
In particular, if you start IPython (with default configuration),
and type

      raise TypeError   # or any other exception

there is a noticeable pause before the traceback.  Even worse,
if code raises an error deep in the call stack, e.g., 8 or 9
levels down, there is a very long pause (e.g., 10 seconds) before
the traceback is displayed.

Note that this weird pause does not occur when using straight python
2.5b with exactly the same code.  Also note that I'm not using pdb.
I noticed that the IPython traceback looks different than Python's
(e.g., no line numbers), so maybe you're doing some interesting magic
there that needs updating for Python 2.5b (or maybe Python 2.5b has
a bug?).

Also, ipdb seems to be completely broken with Python 2.5b.  For
me it will print a traceback and show the prompt, but any attempt
to execute commands, e.g., print names of variables, etc., leads to

ipdb> print n
*** ERROR ***
This version of pdb has a bug and crashed.
Returning to IPython...

---

Anyway, I understand that IPython makes no claims at all about
supporting Python 2.5.   I just wanted to let you know that Python 2.5
seems to be a huge jump, so much so that somebody might have to put
in some significant effort to make IPython work with it.
If you or somebody doing IPython is interested in this, and doesn't
have time to isntall Python 2.5, I can set up an account for them
on sage.math.washington.edu with Python 2.5 and iPython preinstalled.

-- 
William Stein
Associate Professor of Mathematics
University of Washington


From vivian at vdesmedt.com  Tue Jul 25 02:25:05 2006
From: vivian at vdesmedt.com (Vivian De Smedt)
Date: Tue, 25 Jul 2006 08:25:05 +0200
Subject: [IPython-dev] Multi-line history entries
In-Reply-To: <20060724235906.GC11224@pyret>
References: <20060723223415.GA31670@pyret> <44C46AB8.7010303@colorado.edu>
	<44C49687.8090803@vdesmedt.com> <20060724235906.GC11224@pyret>
Message-ID: <44C5B941.1090305@vdesmedt.com>

J?rgen,

Thank you for your explanations.

So according to me:
 - the advantage of your patch is that, when we define a function or a 
class in the shell, the history is not cluttered anymore with 
meaningless chunk of code (the various line of the function that have no 
meaning outside it).
 - the drawback is that if you did something wrong in the middle of a 
function definition you have no chance to correct it using the shell 
history.

Tell me if I'm right.

Regards,
Vivian.


From vivainio at gmail.com  Tue Jul 25 03:09:27 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Tue, 25 Jul 2006 10:09:27 +0300
Subject: [IPython-dev] [Fwd: python2.5]
In-Reply-To: <44C5B6BB.40807@colorado.edu>
References: <44C5B6BB.40807@colorado.edu>
Message-ID: <46cb515a0607250009g646978b6y4f3c777be397f60d@mail.gmail.com>

On 7/25/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:

> Anyway, I understand that IPython makes no claims at all about
> supporting Python 2.5.   I just wanted to let you know that Python 2.5
> seems to be a huge jump, so much so that somebody might have to put
> in some significant effort to make IPython work with it.

Thanks for the heads up.

It's clearly a priority to get it working on python 2.5, but the whole
deal seems to be a regression for python 2.5 rather than an indication
for a need to "fix" ipython. I.e. there's something badly wrong w/
python 2.5 if it breaks lots of stuff (w/o "from __future__ import
blah blah", or deprecationwarnings), and knowing that it flies against
the traditional conservative evolution b/w python versions, one would
expect that future betas of python 2.5 will work better.

-- 
Ville Vainio - vivainio.googlepages.com
vainio.blogspot.com - g[mail | talk]='vivainio'


From fperez.net at gmail.com  Tue Jul 25 03:12:49 2006
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 25 Jul 2006 01:12:49 -0600
Subject: [IPython-dev] [Fwd: python2.5]
In-Reply-To: <46cb515a0607250009g646978b6y4f3c777be397f60d@mail.gmail.com>
References: <44C5B6BB.40807@colorado.edu>
	<46cb515a0607250009g646978b6y4f3c777be397f60d@mail.gmail.com>
Message-ID: <db6b5ecc0607250012i31f12567rbc98dbc6b3fb2732@mail.gmail.com>

On 7/25/06, Ville Vainio <vivainio at gmail.com> wrote:
> On 7/25/06, Fernando Perez <Fernando.Perez at colorado.edu> wrote:
>
> > Anyway, I understand that IPython makes no claims at all about
> > supporting Python 2.5.   I just wanted to let you know that Python 2.5
> > seems to be a huge jump, so much so that somebody might have to put
> > in some significant effort to make IPython work with it.
>
> Thanks for the heads up.
>
> It's clearly a priority to get it working on python 2.5, but the whole
> deal seems to be a regression for python 2.5 rather than an indication
> for a need to "fix" ipython. I.e. there's something badly wrong w/
> python 2.5 if it breaks lots of stuff (w/o "from __future__ import
> blah blah", or deprecationwarnings), and knowing that it flies against
> the traditional conservative evolution b/w python versions, one would
> expect that future betas of python 2.5 will work better.

You may well be right, but in that case we could really help by
reporting such problems before they go official with 2.5.  I'll build
2.5 and play with it to see what's going on, but I'm pretty busy
between now and scipy'06, so I can use all helping hands.

If we really discover serious regressions, we should definitely report
them.  The python-dev team will be a lot less sympathetic to our pleas
if we come after 2.5 is officially out :)

Cheers,

f


From fperez.net at gmail.com  Tue Jul 25 03:35:01 2006
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 25 Jul 2006 01:35:01 -0600
Subject: [IPython-dev] [SAGEdev] python2.5
In-Reply-To: <op.tc8dlfzw81133a@localhost>
References: <op.tc8dlfzw81133a@localhost>
Message-ID: <db6b5ecc0607250035k44cf0748p816cac10ba4e9598@mail.gmail.com>

On 7/24/06, William Stein <wstein at gmail.com> wrote:
> Hi Fernando and Ville,
>
> Have you tried Ipython with Python2.5 beta2 yet?   Since Python2.5
> is supposed to be released in "early August", it might be worth
> thinking about it.  I'm getting SAGE ready for Python 2.5, and
> I noticed that IPython is somewhat broken under Python 2.5.
> In particular, if you start IPython (with default configuration),
> and type
>
>      raise TypeError   # or any other exception
>
> there is a noticeable pause before the traceback.  Even worse,
> if code raises an error deep in the call stack, e.g., 8 or 9
> levels down, there is a very long pause (e.g., 10 seconds) before
> the traceback is displayed.

OK, I just built 2.5b2.  I see the pause...

> Note that this weird pause does not occur when using straight python
> 2.5b with exactly the same code.  Also note that I'm not using pdb.
> I noticed that the IPython traceback looks different than Python's
> (e.g., no line numbers), so maybe you're doing some interesting magic
> there that needs updating for Python 2.5b (or maybe Python 2.5b has
> a bug?).
>
> Also, ipdb seems to be completely broken with Python 2.5b.  For
> me it will print a traceback and show the prompt, but any attempt
> to execute commands, e.g., print names of variables, etc., leads to
>
> ipdb> print n
> *** ERROR ***
> This version of pdb has a bug and crashed.
> Returning to IPython...

And this too.

It seems like we'll have to work quite a bit with it, especially to
ascertain whether the problems are in ipython or in python2.5.  We
really need to report both major performance losses and flat out bugs
to them.  Python2.5 looks great features-wise, but it actually needs
to work :)

Thanks for the heads-up again; this was on my todo list but had
slipped under a mountain of other things...

Ville and I just talked about it, he's also going to build 2.5 and see
what's going on.  Anyone else interested in playing is welcome to
help, we don't actually have all that much time before the release.

cheers,

f


From vivainio at gmail.com  Wed Jul 26 11:35:36 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Wed, 26 Jul 2006 18:35:36 +0300
Subject: [IPython-dev] Multi-line history entries
In-Reply-To: <44C5B941.1090305@vdesmedt.com>
References: <20060723223415.GA31670@pyret> <44C46AB8.7010303@colorado.edu>
	<44C49687.8090803@vdesmedt.com> <20060724235906.GC11224@pyret>
	<44C5B941.1090305@vdesmedt.com>
Message-ID: <46cb515a0607260835p391e4408mb9b2623bf4b5a4eb@mail.gmail.com>

Jorgen Cederlof's patch that makes multiline statements work better
when readline is enabled is now in; I can see the improvement in
linux, but it doesn't help with windows & pyreadline. In any case,
pyreadline version isn't broken (i.e. works as it used to), so the
patch stays in.

Jorgen, many thanks for the contribution! Perhaps Jorgen (Stenarson
this time) can see whether it could be made to work w/ pyreadline as
well...


From walter at livinglogic.de  Wed Jul 26 11:43:57 2006
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Wed, 26 Jul 2006 17:43:57 +0200
Subject: [IPython-dev] Multi-line history entries
In-Reply-To: <46cb515a0607260835p391e4408mb9b2623bf4b5a4eb@mail.gmail.com>
References: <20060723223415.GA31670@pyret>
	<44C46AB8.7010303@colorado.edu>	<44C49687.8090803@vdesmedt.com>
	<20060724235906.GC11224@pyret>	<44C5B941.1090305@vdesmedt.com>
	<46cb515a0607260835p391e4408mb9b2623bf4b5a4eb@mail.gmail.com>
Message-ID: <44C78DBD.7000000@livinglogic.de>

Ville Vainio wrote:
> Jorgen Cederlof's patch that makes multiline statements work better
> when readline is enabled is now in; I can see the improvement in
> linux, but it doesn't help with windows & pyreadline. In any case,
> pyreadline version isn't broken (i.e. works as it used to), so the
> patch stays in.
> 
> Jorgen, many thanks for the contribution! Perhaps Jorgen (Stenarson
> this time) can see whether it could be made to work w/ pyreadline as
> well...

Now that this is checked in I tried it out. This is what happens:

In [1]: for i in xrange(4):
   ...:     print i
   ...:
   ...:
0
1
2
3
In [2]: for i in xrange(4):^J    print i

Is the display supposed to look like that (i.e. display the lines as one
line with a ^J in it), or is my terminal broken? The same happens with
SecureCRT 5.1.2 and putty 0.58 on Windows and with xterm, so I guess the
terminal isn't the problem.

Servus,
   Walter


From vivainio at gmail.com  Thu Jul 27 01:45:33 2006
From: vivainio at gmail.com (Ville Vainio)
Date: Thu, 27 Jul 2006 08:45:33 +0300
Subject: [IPython-dev] Multi-line history entries
In-Reply-To: <44C78DBD.7000000@livinglogic.de>
References: <20060723223415.GA31670@pyret> <44C46AB8.7010303@colorado.edu>
	<44C49687.8090803@vdesmedt.com> <20060724235906.GC11224@pyret>
	<44C5B941.1090305@vdesmedt.com>
	<46cb515a0607260835p391e4408mb9b2623bf4b5a4eb@mail.gmail.com>
	<44C78DBD.7000000@livinglogic.de>
Message-ID: <46cb515a0607262245l3cc86fb9mc5a440b050da5a92@mail.gmail.com>

On 7/26/06, Walter D?rwald <walter at livinglogic.de> wrote:

> Now that this is checked in I tried it out. This is what happens:
>
> In [1]: for i in xrange(4):
>    ...:     print i
>    ...:
>    ...:
> 0
> 1
> 2
> 3
> In [2]: for i in xrange(4):^J    print i

Perhaps this is a problem with your readline version; it worked ok
(i.e. linefeeds were linefeeds) on my home machine (ubuntu dapper).
Anyone else bother giving it a try?

Does stuff w/o autoindenting (e.g. \ line continuation) work ok?

-- 
Ville Vainio - vivainio.googlepages.com
vainio.blogspot.com - g[mail | talk]='vivainio'


From fperez.net at gmail.com  Thu Jul 27 01:51:45 2006
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 26 Jul 2006 23:51:45 -0600
Subject: [IPython-dev] Multi-line history entries
In-Reply-To: <46cb515a0607262245l3cc86fb9mc5a440b050da5a92@mail.gmail.com>
References: <20060723223415.GA31670@pyret> <44C46AB8.7010303@colorado.edu>
	<44C49687.8090803@vdesmedt.com> <20060724235906.GC11224@pyret>
	<44C5B941.1090305@vdesmedt.com>
	<46cb515a0607260835p391e4408mb9b2623bf4b5a4eb@mail.gmail.com>
	<44C78DBD.7000000@livinglogic.de>
	<46cb515a0607262245l3cc86fb9mc5a440b050da5a92@mail.gmail.com>
Message-ID: <db6b5ecc0607262251x29bc9515p2f6496178f2d6f4e@mail.gmail.com>

On 7/26/06, Ville Vainio <vivainio at gmail.com> wrote:
> On 7/26/06, Walter D?rwald <walter at livinglogic.de> wrote:
>
> > Now that this is checked in I tried it out. This is what happens:
> >
> > In [1]: for i in xrange(4):
> >    ...:     print i
> >    ...:
> >    ...:
> > 0
> > 1
> > 2
> > 3
> > In [2]: for i in xrange(4):^J    print i
>
> Perhaps this is a problem with your readline version; it worked ok
> (i.e. linefeeds were linefeeds) on my home machine (ubuntu dapper).
> Anyone else bother giving it a try?

This part looks fine here (but I'm also running dapper, so it's not a
big surprise):


In [1]: for i in range(4):
   ...:     print i,
   ...:
   ...:
0 1 2 3

In [2]: for i in range(4):
    print i,
   ...:     print i+1,
   ...:
   ...:
0 1 1 2 2 3 3 4

In [3]: for i in range(4):
    print i,
    print i+2,
   ...:
   ...:
0 2 1 3 2 4 3 5


Nice enhancement, BTW.  Thanks, Jorgen!

> Does stuff w/o autoindenting (e.g. \ line continuation) work ok?

In [4]: for i in \
   ...: range(4):
   ...:     print i,
   ...:
0 1 2 3


That looks fine to me too.  I'll report any problems I see, but so far
it looks like a net gain, and probably the best that can be done in a
non-curses environment.  But it actually is quite functional, and is a
lot more useful than I'd initially thought.

f


From walter at livinglogic.de  Thu Jul 27 05:37:54 2006
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Thu, 27 Jul 2006 11:37:54 +0200
Subject: [IPython-dev] Multi-line history entries
In-Reply-To: <46cb515a0607262245l3cc86fb9mc5a440b050da5a92@mail.gmail.com>
References: <20060723223415.GA31670@pyret> <44C46AB8.7010303@colorado.edu>	
	<44C49687.8090803@vdesmedt.com> <20060724235906.GC11224@pyret>	
	<44C5B941.1090305@vdesmedt.com>	
	<46cb515a0607260835p391e4408mb9b2623bf4b5a4eb@mail.gmail.com>	
	<44C78DBD.7000000@livinglogic.de>
	<46cb515a0607262245l3cc86fb9mc5a440b050da5a92@mail.gmail.com>
Message-ID: <44C88972.7010106@livinglogic.de>

Ville Vainio wrote:
> On 7/26/06, Walter D?rwald <walter at livinglogic.de> wrote:
> 
>> Now that this is checked in I tried it out. This is what happens:
>>
>> In [1]: for i in xrange(4):
>>    ...:     print i
>>    ...:
>>    ...:
>> 0
>> 1
>> 2
>> 3
>> In [2]: for i in xrange(4):^J    print i
> 
> Perhaps this is a problem with your readline version;

Maybe. I tried it on Debian Sarge.

It happens on Mac OS 10.4.7 too, though.

> it worked ok
> (i.e. linefeeds were linefeeds) on my home machine (ubuntu dapper).
> Anyone else bother giving it a try?
> 
> Does stuff w/o autoindenting (e.g. \ line continuation) work ok?

It looks the same (i.e. one line with ^J).

Servus,
   Walter


From hans_meine at gmx.net  Thu Jul 27 06:22:55 2006
From: hans_meine at gmx.net (Hans Meine)
Date: Thu, 27 Jul 2006 12:22:55 +0200
Subject: [IPython-dev] Multi-line history entries
In-Reply-To: <46cb515a0607262245l3cc86fb9mc5a440b050da5a92@mail.gmail.com>
References: <20060723223415.GA31670@pyret> <44C78DBD.7000000@livinglogic.de>
	<46cb515a0607262245l3cc86fb9mc5a440b050da5a92@mail.gmail.com>
Message-ID: <200607271223.02315.hans_meine@gmx.net>

On Thursday 27 July 2006 07:45, Ville Vainio wrote:
> Perhaps this is a problem with your readline version; it worked ok
> (i.e. linefeeds were linefeeds) on my home machine (ubuntu dapper).
> Anyone else bother giving it a try?
Works here (Gentoo x86/stable, readline-5.1).

One very small thing I noted though: In your example, if you just press enter 
twice to finish the loop, the history will still contain two entries: one 
with the loop construct and one with just the auto-indentation from the next 
line.  I would prefer the latter to vanish, but I don't see the right place 
and condition for another readline.remove_history().
(-> InteractiveShell.push?)

Greetings,
  Hans
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20060727/a8c0a982/attachment.sig>

From bialix at ukr.net  Sat Jul 29 11:40:44 2006
From: bialix at ukr.net (Alexander Belchenko)
Date: Sat, 29 Jul 2006 18:40:44 +0300
Subject: [IPython-dev] Release of pyreadline 1.3
In-Reply-To: <44BD3208.7030401@bostream.nu>
References: <447E8698.8010808@colorado.edu>	<447F47FB.3050203@bostream.nu>	<44866931.2080502@ukr.net>	<44A0313F.80800@bostream.nu>
	<44B9DAC7.5000900@ukr.net> <44BD3208.7030401@bostream.nu>
Message-ID: <eafv75$dfi$1@sea.gmane.org>

J?rgen Stenarson ?????:
> Aleander,
> 
> I could not reproduce your problems. But I have made some additional 
> changes to the color handling so perhaps your problem was fixed. If not 
> please let me know, it would also be useful to know your color settings 
> in the windows console.

New version has the same problem with bright foreground color: it 
convert it to darker equivalent (because in each nibble most significant 
bit is forced to 0).

--
Alexander



> Alexander Belchenko skrev:
>> J?rgen Stenarson ?????:
>>> Alexander Belchenko skrev:
>>>> I download and install new pyreadline and test it with IPython 0.7.1.
>>>> Suddenly this implementation has some undesirable effect (in compare
>>>> with UNC readline): when IPython running it use settings of console for
>>>> foreground color, but in the prompt it try to force to use darker color.
>>>> But I don't want it! And even when I switch manually color of foreground
>>>> for my console back to bright yellow (as my default when IPython
>>>> started) then during multiline editing pyreadline again switch to dark
>>>> yellow color.
>> ...
>>> I have comitted a patch to svn so please try the trunk version and let 
>>> me know if there are any problems.
>> Hmmm. There is problem with that patch.
>>
>> There is no problem with LightBG color scheme but I have problems with 
>> Linux color scheme (at black background).
>>
>> Reproduction of problem in IPython:
>>
>> import os
>> os.path?
>>
>> When I use your original release of pyreadline 1.3 then all docstrings 
>> prints OK. See screenshot original.png.
>>
>> When I install patched version of pyreadline then magic help prints as 
>> black on black. See screenshot patched.png.
>>
>> -- 
>> Alexander
>>
>> ------------------------------------------------------------------------
>>
>>
>> ------------------------------------------------------------------------
>>
> 
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://projects.scipy.org/mailman/listinfo/ipython-dev



From vivian at vdesmedt.com  Sun Jul 30 04:54:10 2006
From: vivian at vdesmedt.com (Vivian De Smedt)
Date: Sun, 30 Jul 2006 10:54:10 +0200
Subject: [IPython-dev] Multi-line history entries
In-Reply-To: <db6b5ecc0607262251x29bc9515p2f6496178f2d6f4e@mail.gmail.com>
References: <20060723223415.GA31670@pyret>
	<44C46AB8.7010303@colorado.edu>	<44C49687.8090803@vdesmedt.com>
	<20060724235906.GC11224@pyret>	<44C5B941.1090305@vdesmedt.com>	<46cb515a0607260835p391e4408mb9b2623bf4b5a4eb@mail.gmail.com>	<44C78DBD.7000000@livinglogic.de>	<46cb515a0607262245l3cc86fb9mc5a440b050da5a92@mail.gmail.com>
	<db6b5ecc0607262251x29bc9515p2f6496178f2d6f4e@mail.gmail.com>
Message-ID: <44CC73B2.8080405@vdesmedt.com>

J?rgen,

I installed your patch on a cygwin version of IPython and it works 
fine.  As Fernando says before it is a lot more useful than I'd 
initially thought.


Thanks again for your patch.
Vivian.