From mantegazza at ill.fr  Tue Apr  5 02:36:57 2005
From: mantegazza at ill.fr (=?iso-8859-15?q?Fr=E9d=E9ric_Mantegazza?=)
Date: Tue, 5 Apr 2005 07:36:57 +0100
Subject: [IPython-dev] Which list updated
Message-ID: <200504050836.58038.mantegazza@ill.fr>

Hello,

I've updated the which list on the wiki. In fact, I found some restrictions 
in execution of magics with runlines() method. Se point 7 at:

    http://www.scipy.org/wikis/featurerequests/IPython

PS: where can I find documentation about the Plone syntax ? I would like to 
make this page a little bit easier to read, using titles or so, and 
creating new pages...

-- 
   Fr?d?ric



From rkern at ucsd.edu  Tue Apr  5 02:52:29 2005
From: rkern at ucsd.edu (Robert Kern)
Date: Mon, 04 Apr 2005 23:52:29 -0700
Subject: [IPython-dev] Re: Which list updated
In-Reply-To: <200504050836.58038.mantegazza@ill.fr>
References: <200504050836.58038.mantegazza@ill.fr>
Message-ID: <d2tcfp$qeo$1@sea.gmane.org>

Fr?d?ric Mantegazza wrote:
> Hello,
> 
> I've updated the which list on the wiki. In fact, I found some restrictions 
> in execution of magics with runlines() method. Se point 7 at:
> 
>     http://www.scipy.org/wikis/featurerequests/IPython
> 
> PS: where can I find documentation about the Plone syntax ? I would like to 
> make this page a little bit easier to read, using titles or so, and 
> creating new pages...

http://zwiki.org/StructuredText

I think.

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



From Fernando.Perez at colorado.edu  Wed Apr  6 07:13:05 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 06 Apr 2005 05:13:05 -0600
Subject: [IPython-dev] Which list updated
In-Reply-To: <200504050836.58038.mantegazza@ill.fr>
References: <200504050836.58038.mantegazza@ill.fr>
Message-ID: <4253C441.7090300@colorado.edu>

Fr?d?ric Mantegazza wrote:
> Hello,
> 
> I've updated the which list on the wiki. In fact, I found some restrictions 
> in execution of magics with runlines() method. Se point 7 at:
> 
>     http://www.scipy.org/wikis/featurerequests/IPython

Please update CVS and give things a try.  Magics can now be used in multiline 
statements (with or wihtout leading %, depending on your %automagic settings). 
  Furthermore, magic calls now honor the same variable expansion mechanism 
which aliases and system calls use:

Here's a trivial example:

In [17]: for i in range(3):
    ....:     mkdir $i
    ....:     !touch $i/hello
    ....:     ls -l $i
    ....:
total 0
-rw-r--r--  1 fperez wavelet 0 Apr  6 05:10 hello
total 0
-rw-r--r--  1 fperez wavelet 0 Apr  6 05:10 hello
total 0
-rw-r--r--  1 fperez wavelet 0 Apr  6 05:10 hello


This required changes in a lot of places, so some hard testing would be very 
welcome before putting it into the wild.  Let me know of any problems.

Best,

f



From mantegazza at ill.fr  Wed Apr  6 10:09:03 2005
From: mantegazza at ill.fr (=?iso-8859-15?q?Fr=E9d=E9ric_Mantegazza?=)
Date: Wed, 6 Apr 2005 15:09:03 +0100
Subject: [IPython-dev] magics in blocks (was Wish list updated)
In-Reply-To: <4253C441.7090300@colorado.edu>
References: <200504050836.58038.mantegazza@ill.fr>
	<4253C441.7090300@colorado.edu>
Message-ID: <200504061609.04097.mantegazza@ill.fr>

Le Mercredi 6 Avril 2005 13:13, Fernando Perez a ?crit :

> Please update CVS and give things a try.  Magics can now be used in
> multiline statements (with or wihtout leading %, depending on your
> %automagic settings). Furthermore, magic calls now honor the same
> variable expansion mechanism which aliases and system calls use:

:o)

> Here's a trivial example:
>
> In [17]: for i in range(3):
>     ....:     mkdir $i
>     ....:     !touch $i/hello
>     ....:     ls -l $i
>     ....:
> total 0
> -rw-r--r--  1 fperez wavelet 0 Apr  6 05:10 hello
> total 0
> -rw-r--r--  1 fperez wavelet 0 Apr  6 05:10 hello
> total 0
> -rw-r--r--  1 fperez wavelet 0 Apr  6 05:10 hello

But I can't make it work this way. It only works if I use ipmagic() 
function...

Here is some examples of the problems without ipmagic(). Note examples 17 
and 18. 'pr' is one of our magic. The behaviour is different than magic 
'cd': when a param follow 'pr', the error occurs just after I hit enter. 
Without param, the error occurs after the blank line. 

I may have a bad config or so...

In [13]:cd
/home/fma

In [14]:for i in xrange(3):
   ....:    cd
   ....:
---------------------------------------------------------------------------
exceptions.NameError                      Traceback (most recent call last)

In [15]:for i in xrange(3):
   ...:    cd /tmp
   ...:
---------------------------------------------------------------------------
exceptions.NameError                      Traceback (most recent call last)

/home/fma/develop/PyMAD/client/ipython/<console>

NameError: name 'cd' is not defined

In [16]:for i in xrange(3):
   ....:    %cd /tmp
------------------------------------------------------------
   File "<console>", line 2
     %cd /tmp
     ^
SyntaxError: invalid syntax

In [17]:for i in range(3):
   ....:    pr
   ....:
---------------------------------------------------------------------------
exceptions.NameError                      Traceback (most recent call last)

/home/fma/develop/PyMAD/client/ipython/<console>

NameError: name 'pr' is not defined

In [18]:for i in range(3):
   ....:    pr a1
------------------------------------------------------------
   File "<console>", line 2
     pr a1
         ^
SyntaxError: invalid syntax

In [18]:for i in range(3):
   ....:    %pr a1
------------------------------------------------------------
   File "<console>", line 2
     %pr a1
     ^
SyntaxError: invalid syntax

In [19]:for i in xrange(3):
   ....:    ipmagic("cd /tmp")
   ....:
/tmp
/tmp
/tmp

In [19]:for mot in ('a1','a2','a3'):
   ....:    ipmagic("pr $mot")
   ....:
angle=+0.00 deg, zero=-5.00 deg, lowLimit=-170.00 deg, highLimit=+190.00 deg
angle=+0.00 deg, zero=+0.00 deg, lowLimit=-180.00 deg, highLimit=+180.00 deg
angle=+0.00 deg, zero=+0.00 deg, lowLimit=-180.00 deg, highLimit=+180.00 deg

-- 
   Fr?d?ric



From Fernando.Perez at colorado.edu  Wed Apr  6 19:52:22 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Wed, 06 Apr 2005 17:52:22 -0600
Subject: [IPython-dev] magics in blocks (was Wish list updated)
In-Reply-To: <200504061609.04097.mantegazza@ill.fr>
References: <200504050836.58038.mantegazza@ill.fr>
	<4253C441.7090300@colorado.edu> <200504061609.04097.mantegazza@ill.fr>
Message-ID: <42547636.7060506@colorado.edu>

Fr?d?ric Mantegazza wrote:
> Le Mercredi 6 Avril 2005 13:13, Fernando Perez a ?crit :
> 
> 
>>Please update CVS and give things a try.  Magics can now be used in
>>multiline statements (with or wihtout leading %, depending on your
>>%automagic settings). Furthermore, magic calls now honor the same
>>variable expansion mechanism which aliases and system calls use:
> 
> 
> :o)
> 
> 
>>Here's a trivial example:
>>
>>In [17]: for i in range(3):
>>    ....:     mkdir $i
>>    ....:     !touch $i/hello
>>    ....:     ls -l $i
>>    ....:
>>total 0
>>-rw-r--r--  1 fperez wavelet 0 Apr  6 05:10 hello
>>total 0
>>-rw-r--r--  1 fperez wavelet 0 Apr  6 05:10 hello
>>total 0
>>-rw-r--r--  1 fperez wavelet 0 Apr  6 05:10 hello
> 
> 
> But I can't make it work this way. It only works if I use ipmagic() 
> function...
> 
> Here is some examples of the problems without ipmagic(). Note examples 17 
> and 18. 'pr' is one of our magic. The behaviour is different than magic 
> 'cd': when a param follow 'pr', the error occurs just after I hit enter. 
> Without param, the error occurs after the blank line. 
> 
> I may have a bad config or so...
> 
> In [13]:cd
> /home/fma
> 
> In [14]:for i in xrange(3):
>    ....:    cd
>    ....:
> ---------------------------------------------------------------------------
> exceptions.NameError                      Traceback (most recent call last)

Please make sure that:

1. You _really_ are running from CVS.

2. In your ipythonrc file, you have

multi_line_specials 1


Without this, it won't work.


For me, the above gives:

In [1]: for i in xrange(3):
    ...:     cd
    ...:
/home/fperez
/home/fperez
/home/fperez


Double check those two things and let me know.

best,

f



From mantegazza at ill.fr  Thu Apr  7 03:24:21 2005
From: mantegazza at ill.fr (=?iso-8859-15?q?Fr=E9d=E9ric_Mantegazza?=)
Date: Thu, 7 Apr 2005 08:24:21 +0100
Subject: [IPython-dev] magics in blocks
In-Reply-To: <42547636.7060506@colorado.edu>
References: <200504050836.58038.mantegazza@ill.fr>
	<200504061609.04097.mantegazza@ill.fr> <42547636.7060506@colorado.edu>
Message-ID: <200504070924.21624.mantegazza@ill.fr>

Le Jeudi 7 Avril 2005 01:52, Fernando Perez a ?crit :

> 2. In your ipythonrc file, you have
>
> multi_line_specials 1
>
>
> Without this, it won't work.

Yes, with this option it works fine :o)))

But is this option really needed ? I mean, is there a reason not to activate 
it ?

Or it could be default to 1, and must be forced to 0 to remove this 
feature...

PS : I will play with all other features to see if something has broken.

-- 
   Fr?d?ric



From Fernando.Perez at colorado.edu  Thu Apr  7 13:22:25 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Thu, 07 Apr 2005 11:22:25 -0600
Subject: [IPython-dev] magics in blocks
In-Reply-To: <200504070924.21624.mantegazza@ill.fr>
References: <200504050836.58038.mantegazza@ill.fr>
	<200504061609.04097.mantegazza@ill.fr> <42547636.7060506@colorado.edu>
	<200504070924.21624.mantegazza@ill.fr>
Message-ID: <42556C51.9070305@colorado.edu>

Fr?d?ric Mantegazza wrote:
> Le Jeudi 7 Avril 2005 01:52, Fernando Perez a ?crit :
> 
> 
>>2. In your ipythonrc file, you have
>>
>>multi_line_specials 1
>>
>>
>>Without this, it won't work.
> 
> 
> Yes, with this option it works fine :o)))
> 
> But is this option really needed ? I mean, is there a reason not to activate 
> it ?
> 
> Or it could be default to 1, and must be forced to 0 to remove this 
> feature...

Look at CVS :)

Best,

f



From mantegazza at ill.fr  Fri Apr  8 02:37:22 2005
From: mantegazza at ill.fr (=?iso-8859-15?q?Fr=E9d=E9ric_Mantegazza?=)
Date: Fri, 8 Apr 2005 07:37:22 +0100
Subject: [IPython-dev] magics in blocks
In-Reply-To: <42556C51.9070305@colorado.edu>
References: <200504050836.58038.mantegazza@ill.fr>
	<200504070924.21624.mantegazza@ill.fr> <42556C51.9070305@colorado.edu>
Message-ID: <200504080837.22529.mantegazza@ill.fr>

Le Jeudi 7 Avril 2005 19:22, Fernando Perez a ?crit :

> > Or it could be default to 1, and must be forced to 0 to remove this
> > feature...
>
> Look at CVS :)

# multi_line_specials: if true, allow magics, aliases and shell escapes (via
# !cmd) to be used in multi-line input (like for loops).  For example, if
# you have this active, the following is valid in IPython:
#
#In [17]: for i in range(3):
#   ....:     mkdir $i
#   ....:     !touch $i/hello
#   ....:     ls -l $i

multi_line_specials 1

Good !

-- 
   Fr?d?ric



From Fernando.Perez at colorado.edu  Fri Apr  8 04:35:41 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Fri, 08 Apr 2005 02:35:41 -0600
Subject: [IPython-dev] heads up - incompatible changes in CVS
Message-ID: <4256425D.8010602@colorado.edu>

Hi all,

If you update CVS, please look at the Changelog.  Two incompatible changes 
were made (for good reasons):

1. pysh users: in your ipythonrc-pysh profile, you MUST:

- add the line
import_all IPython.Extensions.InterpreterExec

- remove the line
execfile pysh.py

Also, delete altogether the file pysh.py from ~/.ipython.  If you had 
additional stuff there, then leave your own stuff, but otherwise remove 
EVERYTHING which came with that file originally.

2. The API for custom tab-completers changed slightly.  I had a bug in it 
(John, I looked more at it, and the state flag really doesn't belong there). 
If you have any custom completers defined, simply remove the state parameter. 
  Custom completers must ONLY take (self,text) as arguments.

Sorry for any trouble this may cause.  I'll reiterate these warnings when this 
gets released for those not using CVS.

Best,

f



From mantegazza at ill.fr  Fri Apr  8 05:03:25 2005
From: mantegazza at ill.fr (=?iso-8859-15?q?Fr=E9d=E9ric_Mantegazza?=)
Date: Fri, 8 Apr 2005 10:03:25 +0100
Subject: [IPython-dev] getdoc hook
Message-ID: <200504081103.25951.mantegazza@ill.fr>

Hello,

I found a way to get Pyro remote object docstrings :o) So I'm trying to 
implement this in IPython. But I have some questions:

1) (not really a IPython specific question) As I have to modify a little bit 
the OInspect.getdoc() function, I'm trying to rebind this function to mine, 
but it does not work :o( How can I do this ? Here is my code:

import PyMAD.client.ipython.IPython.OInspect

def getdoc(obj):
    ....

PyMAD.client.ipython.IPython.OInspect.getdoc = getdoc

Where am I wrong ?

Fernando, could it be possible to add a hook to rebind this function in a 
better way ? It would also be nice to have a hook to change the whole 
getdoc behaviour. I mean, I would like to use my own Inspector class (at 
least to be able to overide some parts of it).

2) Why is the getdoc() function always called, even when I don't use the 
'obj?' syntax ?

3) Is it possible make difference in 'obj.?' and 'obj.??' syntaxes at the 
getdoc() level ? If not, where is it handled ?

-- 
   Fr?d?ric



From Fernando.Perez at colorado.edu  Fri Apr  8 05:24:54 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Fri, 08 Apr 2005 03:24:54 -0600
Subject: [IPython-dev] getdoc hook
In-Reply-To: <200504081103.25951.mantegazza@ill.fr>
References: <200504081103.25951.mantegazza@ill.fr>
Message-ID: <42564DE6.2070306@colorado.edu>

Fr?d?ric Mantegazza wrote:
> Hello,
> 
> I found a way to get Pyro remote object docstrings :o) So I'm trying to 
> implement this in IPython. But I have some questions:
> 
> 1) (not really a IPython specific question) As I have to modify a little bit 
> the OInspect.getdoc() function, I'm trying to rebind this function to mine, 
> but it does not work :o( How can I do this ? Here is my code:
> 
> import PyMAD.client.ipython.IPython.OInspect
> 
> def getdoc(obj):
>     ....
> 
> PyMAD.client.ipython.IPython.OInspect.getdoc = getdoc
> 
> Where am I wrong ?

I'm not really sure why it's not working, what you are doing looks perfectly 
reasonable to me.

> Fernando, could it be possible to add a hook to rebind this function in a 
> better way ? 

Well, this is not really an ipython internal method which is hookable, it's 
just a plain function in a library (the OInspect module).  So what you are 
doing is about as simple a rebind as I can imagine (though I don't understand 
why it's failing in your case, sorry).

> It would also be nice to have a hook to change the whole 
> getdoc behaviour. I mean, I would like to use my own Inspector class (at 
> least to be able to overide some parts of it).

Well, you can use your own inspector simply by setting:

__IPYTHON__.inspector = your_inspector_instance

> 2) Why is the getdoc() function always called, even when I don't use the 
> 'obj?' syntax ?

Because in the input evaluation loop, while I find what you typed (to make 
auto-execution decisions and the like), once the object is found I fish out in 
passing the docstring.  A lot of the machinery that does many of the nice 
things in ipython needs to know quite a bit about the objects referenced by 
names at the command line, so I tried to centralize this collection of 
information in one place.  The actual routine is _ofind() in Magic.py (that 
probably belongs somewhere else like iplib.py, really).

> 3) Is it possible make difference in 'obj.?' and 'obj.??' syntaxes at the 
> getdoc() level ? If not, where is it handled ?

No.  getdoc() gets passed a true object, not the input line which the user 
typed.  By the time getdoc is called, we've long forgotten the user input.  If 
you need to mess with that kind of thing, you need to put traps very early on 
in the line processing, that's what custom prefilters are for.  Note that 
obj.?  doesn't work:

In [2]: code.?
Object `code.` not found.

because the dot is taken as part of the name.  If you want things to work with 
that dot, you'll have to do custom handling at the prefilter level, since 
'foo.' can never be a valid python object name.

Best,

f



From mantegazza at ill.fr  Fri Apr  8 09:01:09 2005
From: mantegazza at ill.fr (=?iso-8859-15?q?Fr=E9d=E9ric_Mantegazza?=)
Date: Fri, 8 Apr 2005 14:01:09 +0100
Subject: [IPython-dev] getdoc hook
In-Reply-To: <42564DE6.2070306@colorado.edu>
References: <200504081103.25951.mantegazza@ill.fr>
	<42564DE6.2070306@colorado.edu>
Message-ID: <200504081501.09860.mantegazza@ill.fr>

Le Vendredi 8 Avril 2005 11:24, Fernando Perez a ?crit :

> > Fernando, could it be possible to add a hook to rebind this function in
> > a better way ?
>
> Well, this is not really an ipython internal method which is hookable,
> it's just a plain function in a library (the OInspect module).  So what
> you are doing is about as simple a rebind as I can imagine (though I
> don't understand why it's failing in your case, sorry).

I will look further why it does not work...

> > It would also be nice to have a hook to change the whole
> > getdoc behaviour. I mean, I would like to use my own Inspector class
> > (at least to be able to overide some parts of it).
>
> Well, you can use your own inspector simply by setting:
>
> __IPYTHON__.inspector = your_inspector_instance

This is fine :o)

> > 2) Why is the getdoc() function always called, even when I don't use
> > the 'obj?' syntax ?
>
> Because in the input evaluation loop, while I find what you typed (to
> make auto-execution decisions and the like), once the object is found I
> fish out in passing the docstring.  A lot of the machinery that does many
> of the nice things in ipython needs to know quite a bit about the objects
> referenced by names at the command line, so I tried to centralize this
> collection of information in one place.  The actual routine is _ofind()
> in Magic.py (that probably belongs somewhere else like iplib.py, really).

So I will always have a call to the remote object getdoc() method (little 
overhead)...

> > 3) Is it possible make difference in 'obj.?' and 'obj.??' syntaxes at
> > the getdoc() level ? If not, where is it handled ?
>
> No. getdoc() gets passed a true object, not the input line which the
> user typed.  By the time getdoc is called, we've long forgotten the user
> input.  If you need to mess with that kind of thing, you need to put
> traps very early on in the line processing, that's what custom prefilters
> are for.

It was more for my general understanding rather than for a real need.

> Note that obj.?  doesn't work: 

Sorry, it was an error. I didn't want to say 'obj.?', but 'obj?'.

Thank's,

-- 
   Fr?d?ric



From Fernando.Perez at colorado.edu  Fri Apr  8 09:17:07 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Fri, 08 Apr 2005 07:17:07 -0600
Subject: [IPython-dev] getdoc hook
In-Reply-To: <200504081501.09860.mantegazza@ill.fr>
References: <200504081103.25951.mantegazza@ill.fr>
	<42564DE6.2070306@colorado.edu> <200504081501.09860.mantegazza@ill.fr>
Message-ID: <42568453.9070805@colorado.edu>

Fr?d?ric Mantegazza wrote:
> Le Vendredi 8 Avril 2005 11:24, Fernando Perez a ?crit :

>>>2) Why is the getdoc() function always called, even when I don't use
>>>the 'obj?' syntax ?
>>
>>Because in the input evaluation loop, while I find what you typed (to
>>make auto-execution decisions and the like), once the object is found I
>>fish out in passing the docstring.  A lot of the machinery that does many
>>of the nice things in ipython needs to know quite a bit about the objects
>>referenced by names at the command line, so I tried to centralize this
>>collection of information in one place.  The actual routine is _ofind()
>>in Magic.py (that probably belongs somewhere else like iplib.py, really).
> 
> 
> So I will always have a call to the remote object getdoc() method (little 
> overhead)...

Well, let me see if I can clean that up a bit.  I really don't like the fact 
that _ofind() fishes out the docstring always, since quite often you don't 
really need it.  I may be able to change things so that getdoc() only gets 
called if the docstring is actually going to be used.  Stay tuned.

Best,

f



From Fernando.Perez at colorado.edu  Fri Apr  8 10:18:06 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Fri, 08 Apr 2005 08:18:06 -0600
Subject: [IPython-dev] getdoc hook
In-Reply-To: <42568453.9070805@colorado.edu>
References: <200504081103.25951.mantegazza@ill.fr>
	<42564DE6.2070306@colorado.edu> <200504081501.09860.mantegazza@ill.fr>
	<42568453.9070805@colorado.edu>
Message-ID: <4256929E.2050409@colorado.edu>

Fernando Perez wrote:
> Fr?d?ric Mantegazza wrote:

>>So I will always have a call to the remote object getdoc() method (little 
>>overhead)...
> 
> 
> Well, let me see if I can clean that up a bit.  I really don't like the fact 
> that _ofind() fishes out the docstring always, since quite often you don't 
> really need it.  I may be able to change things so that getdoc() only gets 
> called if the docstring is actually going to be used.  Stay tuned.

OK, I cleaned things up and now getdoc() should only get called (once) when 
it's actually needed.  This is much better, please test and let me know how it 
goes.

Best

f



From mantegazza at ill.fr  Fri Apr  8 11:50:53 2005
From: mantegazza at ill.fr (=?iso-8859-15?q?Fr=E9d=E9ric_Mantegazza?=)
Date: Fri, 8 Apr 2005 16:50:53 +0100
Subject: [IPython-dev] getdoc hook
In-Reply-To: <4256929E.2050409@colorado.edu>
References: <200504081103.25951.mantegazza@ill.fr>
	<42568453.9070805@colorado.edu> <4256929E.2050409@colorado.edu>
Message-ID: <200504081750.53802.mantegazza@ill.fr>

Le Vendredi 8 Avril 2005 16:18, Fernando Perez a ?crit :

> OK, I cleaned things up and now getdoc() should only get called (once)
> when it's actually needed.  This is much better, please test and let me
> know how it goes.

Nice work !

Have a good week-end,

-- 
   Fr?d?ric



From Fernando.Perez at colorado.edu  Thu Apr 14 18:11:57 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Thu, 14 Apr 2005 16:11:57 -0600
Subject: [IPython-dev] IPython 0.6.13 is out.
Message-ID: <425EEAAD.4010203@colorado.edu>

Hi all,

I'm glad to announce the release of IPython 0.6.13.

IPython's homepage is at:

http://ipython.scipy.org

and downloads are at:

http://ipython.scipy.org/dist

I've provided RPMs (for Python 2.3 and 2.4, built under Fedora Core 3), plus
source downloads (.tar.gz).  Fedora users should note that IPython is now 
officially part of the Extras repository, so they can get the update from 
there as well (though it may lag by a few days).

There is also a native win32 installer which should work correctly for both 
Python 2.3 and 2.4.

Debian, Fink and BSD packages for this version should be coming soon, as the
respective maintainers (many thanks to Jack Moffit, Andrea Riciputi and Dryice
Liu) have the time to follow their packaging procedures.

Many thanks to Enthought for their continued hosting support for IPython, and
to all the users who contributed ideas, fixes and reports.  In particular, 
thanks to Frederic Mantegazza for extensive discussions on embedding features 
which make ipython suitable for use in the kind of complex environments I had 
always wanted it to be used.


Release notes
-------------

*** WARNING to pysh users *** A backwards-incompatible change has been made.

1. You must update your pysh profile (~/.ipython/ipythonrc-pysh):

   a) Add to it the line:

	import_all IPython.Extensions.InterpreterExec

   b) Delete the line

	execfile pysh.py

2. You must also delete from ~/.ipython/ the file pysh.py.

*** END pysh warning.


As always, the NEWS file can be found at http://ipython.scipy.org/NEWS, and
the full ChangeLog at http://ipython.scipy.org/ChangeLog.  The highlights of 
this release follow.

* Improved variable capture from system commands.  The %sc and %sx magics (and 
   hence the !!syntax in Pysh) now capture to special objects which, while 
looking like strings/lists, provide automatic conversion between the various 
modes:

In [12]: sc a=ls s*py

In [13]: a  # the returned object looks like a plain string
Out[13]: 'sanner.py\nscopes.py\nsplot.py\nstrings.py'

In [14]: a.s  # but you can see it as a string with pure whitespace
Out[14]: 'sanner.py scopes.py splot.py strings.py'

In [15]: a.l  # as a list
Out[15]: ['sanner.py', 'scopes.py', 'splot.py', 'strings.py']

In [16]: a.n  # or as a string with newlines
Out[16]: 'sanner.py\nscopes.py\nsplot.py\nstrings.py'

If you capture the result split as a list, the returned object exhibits the 
exact same interface with .s, .l and .n attributes:

In [18]: sc -l b=ls s*py

In [19]: b
Out[19]: ['sanner.py', 'scopes.py', 'splot.py', 'strings.py']

In [20]: b.s
Out[20]: 'sanner.py scopes.py splot.py strings.py'

In [21]: b.l
Out[21]: ['sanner.py', 'scopes.py', 'splot.py', 'strings.py']

In [22]: b.n
Out[22]: 'sanner.py\nscopes.py\nsplot.py\nstrings.py'

Try the above and use a? and b? to see the full docstrings of these special 
objects, which can be extremely convenient when manipulating system commands 
output.

* By default, IPython now binds the up/down arrow keys to search only in the 
history which matches your input so far.  If you are an old user your 
ipythonrc file is NOT automatically updated, but you can get this effect by 
putting the following in it:

readline_parse_and_bind "\e[A": history-search-backward
readline_parse_and_bind "\e[B": history-search-forward

* Many changes and improvements to make it easier to embed ipython into 
complex interactive environments.  These changes were motivated by the needs 
of Frederic Mantegazza, and more details can be found on the -dev list 
archives and at this wiki page specially created for this discussion:

http://www.scipy.org/wikis/featurerequests/IPython

In particular, ipython now exposes the ability to set custom exception 
handlers, docstring extraction methods, custom tab-completion routines, and 
more.  That wiki page also serves as documentation (with code examples)  for 
some of these more complex features.

IPython also now exposes its own input execution routine (the runlines() 
method).  You can thus feed this method snippets of input (even multiline) 
with magic syntax and all other special extensions, which it will process as 
if they had been typed at the command line.

* Multi-line specials are now active by default.  This means that you can use 
special syntax, like !cmd, in python multi-line input.  A silly example:

In [26]: for i in range(3):
    ....:     !ls $i
    ....:
ls: 0: No such file or directory
ls: 1: No such file or directory
ls: 2: No such file or directory

* Magics can also be called in multi-line input, and python variables can be 
expanded in magics just like in system calls or aliases:

In [36]: mydir='/usr/include/atlas'

In [37]: cd mydir
[Errno 2] No such file or directory: 'mydir'
/home/fperez

In [38]: cd $mydir
/usr/include/atlas

This brings consistency to the various special subsystems in ipython: they ALL 
expand python expressions with the same rules (those of Itpl linked to above), 
and they can all be used in multiline input.

* Dynamic prompt strings.  Now, the following ${foo()+x+bar.baz()} is a valid 
prompt string, where foo, x and bar will be evaluated at runtime from your 
interactive namespace.  Arbitrary Python expressions, according to the Itpl 
design, can be thus used (see http://www.python.org/peps/pep-0215.html for 
details on Itpl).

* Fixes for (X)Emacs prompt support (hung file queue when executing files from 
an emacs buffer).

* Fixes (thanks to John Hunter) for tab-completion in the face of broken 
objects on which dir() returns anything other than a list of pure strings 
(such as the ITK library).

* Other small fixes and cleanups.


Enjoy, and as usual please report any problems.

Regards,

Fernando.



From Fernando.Perez at colorado.edu  Thu Apr 14 19:19:08 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Thu, 14 Apr 2005 17:19:08 -0600
Subject: [IPython-dev] Towards IPython 1.0, the famous big cleanup
Message-ID: <425EFA6C.30701@colorado.edu>

Hi all,

I'd stopped talking about the famous 'big cleanup' because I was really 
looking like a fool.  But it's really time to get to it.  I have a growing 
list of things I want to do with IPython and which are simply impossible with 
the current structure.

This means that 0.6.13, just released, will most likely be the last release 
for quite a while.  I'm going to be mostly off-line for 2 weeks, which I'll 
consider settling-down time for this release.  If any significant bugs are 
reported in that period, I'll cut a .14 with the fixes, otherwise when I 
return I'll start ripping into the code.

The changes made for Frederic Mantegazza/PyMAD showed at the same time that 
the current code can really be used for fairly sophisticated things, but that 
the architectural limitations make much of this painful.  The fact that it 
looks pretty robust in such an environment makes me comfortable calling a 
'deep freeze' which will probably last several months (ipython is a 'spare 
time' project, after all).

So if you have some really critical bug which is driving you crazy, either 
report it (preferably with a patch) in the next 2-3 weeks, or prepare to live 
with it for quite a while.  The moment I commit the first change to CVS, I 
will simply have to ignore EVERY REQUEST made, until the new shiny ipython 
emerges from the process, reborn in a glory which shall blind the world.  I'm 
sorry to put it this way, but since I do this alone, I simply lack enough 
resources to develop a new codebase while maintaining the current one.

It has been months since a crash has been reported in active code (I do get 
occasional crash reports from users running out-of-date versions).  Because of 
this, I don't think this freeze will be too problematic for anyone.

I should note that in the rewrite, I will make all sorts of incompatible 
changes to pretty much everything.  So if you are a developer of a project 
which uses ipython, unfortunately things will break.  I won't make gratuitous 
changes, but many things in the current system are just too broken to live 
with.  Hopefully the pain will be worth it, as I expect the new system to have 
a far cleaner API for all kinds of customizations and embeddings.  This can be 
done in the current code only because Python allows you to change pretty much 
ANYTHING you want on a running object, not because of any valid design or API. 
  I expect to fix this.

The two most visible changes for embedders and customizers:

- The configuration system will shift from the ad-hoc ipythonrc format to 
proper .py Python source files.  We will thus benefit from the Python compiler 
and engine for code customization, and the configuration loading system will 
be far, far simpler in the end.  I also expect startup times to decrease 
thanks to these changes.

- the magic system will be fully overhauled.  The core of your custom magics 
will most likely run unchanged, but how they plug into ipython will change.


I hope the changes will be worth it, and when the dust settles, we'll have 
something we can call IPython 1.0.  While the current code works quite well, 
I've never wanted to call it 1.0 simply because I consider its (non-existent) 
API to be a prototype.  Once I call something 1.0, I am in a sense committing 
to a reasonably stable public API, which users can rely on (barring gross 
mistakes or bugs) for their own projects in the long run.

As always, I'll welcome any comments, discussion, ideas, patches or help in 
this process.

Regards to all,

Fernando.



From mantegazza at ill.fr  Fri Apr 15 07:19:56 2005
From: mantegazza at ill.fr (=?iso-8859-15?q?Fr=E9d=E9ric_Mantegazza?=)
Date: Fri, 15 Apr 2005 12:19:56 +0100
Subject: [IPython-dev] Towards IPython 1.0, the famous big cleanup
In-Reply-To: <425EFA6C.30701@colorado.edu>
References: <425EFA6C.30701@colorado.edu>
Message-ID: <200504151319.57796.mantegazza@ill.fr>

Le Vendredi 15 Avril 2005 01:19, Fernando Perez a ?crit :

> The changes made for Frederic Mantegazza/PyMAD showed at the same time
> that the current code can really be used for fairly sophisticated things,
> but that the architectural limitations make much of this painful.  The
> fact that it looks pretty robust in such an environment makes me
> comfortable calling a 'deep freeze' which will probably last several
> months (ipython is a 'spare time' project, after all).

I just want to say that using IPython is really great. We chose it for our 
application to avoid the need to re-write all its wonderfull features 
(completion, history, magic commands...).

Our application also use Pyro, a remote server objects, and using Pyro 
within IPython needed to add some little hack in IPython. At first, 
Fernando explained me how to do these hacks, and in the same time, started 
to add some hooks in its code. The 0.6.13 version contains all these 
hooks :o)

Users are very happy of the completion and docstrings on Pyro remote 
objects, to have a customizable prompt (which is used as a simple status 
bar), to have a simplified traceback on PyMAD exceptions and to be able to 
mix up python code and magic commands in batch files.

So, I would like to thank you again, Fernando, for the great job you did 
during the last months. I really appreciate. And don't worry, I think I 
will have some more ideas to interact with IPython, for the 1.0 relase ;o)

PS : and I confirm that IPython is very robust, has our application runs 24 
hours a day, without any problem.

-- 
   Fr?d?ric



From vivainio at kolumbus.fi  Fri Apr 15 12:57:52 2005
From: vivainio at kolumbus.fi (Ville Vainio)
Date: Fri, 15 Apr 2005 19:57:52 +0300
Subject: [IPython-dev] Towards IPython 1.0, the famous big cleanup
In-Reply-To: <425EFA6C.30701@colorado.edu>
References: <425EFA6C.30701@colorado.edu>
Message-ID: <1113584273.10208.18.camel@localhost.localdomain>

On Thu, 2005-04-14 at 17:19 -0600, Fernando Perez wrote:

> - the magic system will be fully overhauled.  The core of your custom magics 
> will most likely run unchanged, but how they plug into ipython will change.

I've probably said this before, but -

Do we need a magic system at all?

It would be cleaner if what are now "magic" would be just normal Python
functions/callables, with some additional metadata about how it wants to
receive the argument string. To behave exactly like magics (apart from
separate namespace and %), it would just need to take a single string
(the whole command line) as argument. 

Shell commands would all refer to the same object, one that takes the
whole command line and does the deed.

Other command line metadata information could be added to provide
alternative completion mechanisms - for example 'cd' might only show
dirs as filename completions (a contorted example):

@ipy_func_completers(ipy_isdir_completer)
def cd(path):
	os.chdir(path)


A 'sendmoney' func always interprets the first arg as string, w/o need
to quote:


@ipy_argtypes(str,int)
def sendmoney(recipient, amount):
	pass


sendmoney ville,10000 # works
sendmoney "ville vainio",10000 # also works

Of course the system could be extended indefinitely this way.



From Fernando.Perez at colorado.edu  Fri Apr 15 14:27:31 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Fri, 15 Apr 2005 12:27:31 -0600
Subject: [IPython-dev] Towards IPython 1.0, the famous big cleanup
In-Reply-To: <1113584273.10208.18.camel@localhost.localdomain>
References: <425EFA6C.30701@colorado.edu>
	<1113584273.10208.18.camel@localhost.localdomain>
Message-ID: <42600793.5070306@colorado.edu>

Ville Vainio wrote:
> On Thu, 2005-04-14 at 17:19 -0600, Fernando Perez wrote:
> 
> 
>>- the magic system will be fully overhauled.  The core of your custom magics 
>>will most likely run unchanged, but how they plug into ipython will change.
> 
> 
> I've probably said this before, but -
> 
> Do we need a magic system at all?
> 
> It would be cleaner if what are now "magic" would be just normal Python
> functions/callables, with some additional metadata about how it wants to
> receive the argument string. To behave exactly like magics (apart from
> separate namespace and %), it would just need to take a single string
> (the whole command line) as argument. 

Well, that's pretty much what they do today.  It's just that making a new 
magic involves binding by hand an instance method with a special name, for 
example:

from IPython.iplib import InteractiveShell

def magic_runbatch(self, parameter_s=''):
     """ runbatch magic command.
     """
     try:
         fileobj = open(parameter_s,'r')
     except:
         print "Error: could not open file",parameter_s
         return
     else:
         self.shell.runlines(fileobj.read())

InteractiveShell.magic_runbatch = magic_runbatch
del magic_runbatch

What I envision, is something cleaner, more like:

__IPYTHON__.set_new_magic(your_function,optional_name='mymagic',opt_args=...)

And that's it.  Any function you write can be made into a magic, as long as it 
conforms to a minimal API.  When I actually start working on this (probably 
item #2 after the config system rewrite), I'll make sure to post my plan to 
this list, so anyone with thoughts/criticisms can voice them early on before I 
spend too much time coding myself into a silly corner.

> Shell commands would all refer to the same object, one that takes the
> whole command line and does the deed.

Again, today we pretty much have this already, it's just not cleanly indicated 
and documented.

But thanks for the comments: I _really_ want people to voice any and all 
concerns or ideas they may have in this direction.  I hope that when 1.0 comes 
out, we can be reasonably happy that the publicly exposed API is stable enough 
that users can rely on it for a while.  So by all means, speak up!

Best,

f



From jack at xiph.org  Fri Apr 15 14:33:24 2005
From: jack at xiph.org (Jack Moffitt)
Date: Fri, 15 Apr 2005 12:33:24 -0600
Subject: [IPython-dev] Towards IPython 1.0, the famous big cleanup
In-Reply-To: <42600793.5070306@colorado.edu>
References: <425EFA6C.30701@colorado.edu>
	<1113584273.10208.18.camel@localhost.localdomain>
	<42600793.5070306@colorado.edu>
Message-ID: <20050415183324.GP10545@i.cantcode.com>

> magic involves binding by hand an instance method with a special name, for 
> example:
> 
> from IPython.iplib import InteractiveShell
> 
> def magic_runbatch(self, parameter_s=''):
>     """ runbatch magic command.
>     """
>     try:
>         fileobj = open(parameter_s,'r')
>     except:
>         print "Error: could not open file",parameter_s
>         return
>     else:
>         self.shell.runlines(fileobj.read())
> 
> InteractiveShell.magic_runbatch = magic_runbatch
> del magic_runbatch
> 
> What I envision, is something cleaner, more like:
> 
> __IPYTHON__.set_new_magic(your_function,optional_name='mymagic',opt_args=...)

Not that I like the new decorator syntax, but something like:

@InteractiveShell.magicmethod
def run_batch(...)
   ...

Is pretty easy to read and grok.

jack.



From Fernando.Perez at colorado.edu  Fri Apr 15 14:44:17 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Fri, 15 Apr 2005 12:44:17 -0600
Subject: [IPython-dev] Towards IPython 1.0, the famous big cleanup
In-Reply-To: <20050415183324.GP10545@i.cantcode.com>
References: <425EFA6C.30701@colorado.edu>
	<1113584273.10208.18.camel@localhost.localdomain>
	<42600793.5070306@colorado.edu> <20050415183324.GP10545@i.cantcode.com>
Message-ID: <42600B81.3030901@colorado.edu>

Jack Moffitt wrote:
>>magic involves binding by hand an instance method with a special name, for 
>>example:
>>
>>from IPython.iplib import InteractiveShell
>>
>>def magic_runbatch(self, parameter_s=''):
>>    """ runbatch magic command.
>>    """
>>    try:
>>        fileobj = open(parameter_s,'r')
>>    except:
>>        print "Error: could not open file",parameter_s
>>        return
>>    else:
>>        self.shell.runlines(fileobj.read())
>>
>>InteractiveShell.magic_runbatch = magic_runbatch
>>del magic_runbatch
>>
>>What I envision, is something cleaner, more like:
>>
>>__IPYTHON__.set_new_magic(your_function,optional_name='mymagic',opt_args=...)
> 
> 
> Not that I like the new decorator syntax, but something like:
> 
> @InteractiveShell.magicmethod
> def run_batch(...)
>    ...
> 
> Is pretty easy to read and grok.

Yup, but that's 2.4.  I'm trying to hold on to 2.2 compatibility for as long 
as I can.  That may be too much to ask, but definitely 2.3 will be a target, 
so 2.4-specific features may be out.

f



From jack at xiph.org  Fri Apr 15 14:50:27 2005
From: jack at xiph.org (Jack Moffitt)
Date: Fri, 15 Apr 2005 12:50:27 -0600
Subject: [IPython-dev] Towards IPython 1.0, the famous big cleanup
In-Reply-To: <42600B81.3030901@colorado.edu>
References: <425EFA6C.30701@colorado.edu>
	<1113584273.10208.18.camel@localhost.localdomain>
	<42600793.5070306@colorado.edu> <20050415183324.GP10545@i.cantcode.com>
	<42600B81.3030901@colorado.edu>
Message-ID: <20050415185027.GQ10545@i.cantcode.com>

> >Not that I like the new decorator syntax, but something like:
> >
> >@InteractiveShell.magicmethod
> >def run_batch(...)
> >   ...
> >
> >Is pretty easy to read and grok.
> 
> Yup, but that's 2.4.  I'm trying to hold on to 2.2 compatibility for as 
> long as I can.  That may be too much to ask, but definitely 2.3 will be a 
> target, so 2.4-specific features may be out.

You can easily do both (I think).  Just make your new_magic_method(x) do:

x = InteractiveShell.magicmethod(x)

Then people adding new magic (if they are using 2.4) can use the easier
decorator syntax, and the rest of the world can do it however they want
:)

Anyway, I've been reading various cool tricks people are doing with
decorators, so I had it on the brain :)

jack.



From Fernando.Perez at colorado.edu  Fri Apr 15 15:08:14 2005
From: Fernando.Perez at colorado.edu (Fernando Perez)
Date: Fri, 15 Apr 2005 13:08:14 -0600
Subject: [IPython-dev] Towards IPython 1.0, the famous big cleanup
In-Reply-To: <20050415185027.GQ10545@i.cantcode.com>
References: <425EFA6C.30701@colorado.edu>
	<1113584273.10208.18.camel@localhost.localdomain>
	<42600793.5070306@colorado.edu> <20050415183324.GP10545@i.cantcode.com>
	<42600B81.3030901@colorado.edu> <20050415185027.GQ10545@i.cantcode.com>
Message-ID: <4260111E.8060306@colorado.edu>

Jack Moffitt wrote:
>>>Not that I like the new decorator syntax, but something like:
>>>
>>>@InteractiveShell.magicmethod
>>>def run_batch(...)
>>>  ...
>>>
>>>Is pretty easy to read and grok.
>>
>>Yup, but that's 2.4.  I'm trying to hold on to 2.2 compatibility for as 
>>long as I can.  That may be too much to ask, but definitely 2.3 will be a 
>>target, so 2.4-specific features may be out.
> 
> 
> You can easily do both (I think).  Just make your new_magic_method(x) do:
> 
> x = InteractiveShell.magicmethod(x)
> 
> Then people adding new magic (if they are using 2.4) can use the easier
> decorator syntax, and the rest of the world can do it however they want
> :)
> 
> Anyway, I've been reading various cool tricks people are doing with
> decorators, so I had it on the brain :)

I'll keep it in mind, thanks for the feedback.  If it's possible to make it 
decorator-friendly, I'll definitely do so.  I'll have to see in practice if it 
all works out, but in principle I don't see why not (I just worry about 
mucking with the running instance, but I haven't really thought about it).

And I agree, decorators are also growing on me.  It's just that I want to 
avoid _requiring_ them for ipython.

Best,

f



From vivainio at kolumbus.fi  Tue Apr 19 14:05:27 2005
From: vivainio at kolumbus.fi (Ville Vainio)
Date: Tue, 19 Apr 2005 21:05:27 +0300
Subject: [IPython-dev] Towards IPython 1.0, the famous big cleanup
In-Reply-To: <42600793.5070306@colorado.edu>
References: <425EFA6C.30701@colorado.edu>
	<1113584273.10208.18.camel@localhost.localdomain>
	<42600793.5070306@colorado.edu>
Message-ID: <1113933927.11621.2.camel@localhost.localdomain>

On Fri, 2005-04-15 at 12:27 -0600, Fernando Perez wrote:

> > Do we need a magic system at all?

> Well, that's pretty much what they do today.  It's just that making a new 
> magic involves binding by hand an instance method with a special name, for 
> example:

Yeah, but it's still "magic system". It could be just a bunch of normal
python objects, visible normally, without a need to lookup a special
dictionary of magic methods (and another for aliases, etc.).

Of course it would work pretty much the same, but it would be simpler
and more orthogonal.




From gsakkis at eden.rutgers.edu  Wed Apr 20 00:59:56 2005
From: gsakkis at eden.rutgers.edu (gsakkis at eden.rutgers.edu)
Date: Wed, 20 Apr 2005 00:59:56 -0400 (EDT)
Subject: [IPython-dev] Default parameter completer
Message-ID: <61524.68.197.31.58.1113973196.squirrel@webmail.eden.rutgers.edu>

Hello all,

I've written a matcher that provides the available default keyword arguments for
the most recent open call; check below for a snapshot of interactive usage. It's
not perfect (e.g. it cannot handle builtins), but I think it's adequate for most
cases.

I just subscribed to the list, so I have two questions on integrating new features:
- What's the procedure for adding a new feature to the official release (of
course if is deemed good, original and useful enough) ?
- If for any reason it can't make it to the official release, what's the
suggested way to integrate it in my own copy ? Currently I simply hacked
iplib.py, but I wonder if there's a more elegant way to add new functionality.

Thanks,
George


#=== Snapshot ========================================================

Python 2.4 (#1, Mar 29 2005, 15:15:45)
Type "copyright", "credits" or "license" for more information.

IPython 0.6.12 -- An enhanced Interactive Python.
?       -> Introduction to IPython's features.
%magic  -> Information about IPython's 'magic' % functions.
help    -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.

In [1]:%autoindent
Automatic indentation is: OFF

In [2]:def func(x, longDefaultArgumentFoo=0, longDefaultArgumentBar=None):
   ...:      pass
   ...:
In [3]:class Klass(object):
   ...:      def __init__(self, longDefaultInitArgument=""):
   ...:          pass
   ...:      def __call__(self, longDefaultCallArgument=-1):
   ...:          pass
   ...:      method = func
   ...:
In [4]:func(abs(3), lon
long                     longDefaultArgumentBar=  longDefaultArgumentFoo=

In [4]:func(abs(3), longD
longDefaultArgumentBar=  longDefaultArgumentFoo=

In [4]:func(abs(3), longDefaultArgumentFoo=34)

In [5]:obj = Klass(long
long                      longDefaultInitArgument=

In [5]:obj = Klass(longDefaultInitArgument=None)

In [6]:obj.method(longD
longDefaultArgumentBar=  longDefaultArgumentFoo=

In [6]:obj.method(longDefaultArgumentBar=0, longD
longDefaultArgumentBar=  longDefaultArgumentFoo=

In [6]:obj.method(longDefaultArgumentBar=0, longDefaultArgumentFoo=12)

In [7]:obj(long
long                      longDefaultCallArgument=

In [7]:obj(longDefaultCallArgument="")





From mantegazza at ill.fr  Wed Apr 20 02:22:19 2005
From: mantegazza at ill.fr (=?iso-8859-15?q?Fr=E9d=E9ric_Mantegazza?=)
Date: Wed, 20 Apr 2005 07:22:19 +0100
Subject: [IPython-dev] Default parameter completer
In-Reply-To: <61524.68.197.31.58.1113973196.squirrel@webmail.eden.rutgers.edu>
References: <61524.68.197.31.58.1113973196.squirrel@webmail.eden.rutgers.edu>
Message-ID: <200504200822.20445.mantegazza@ill.fr>

Le Mercredi 20 Avril 2005 06:59, gsakkis at eden.rutgers.edu a ?crit :

> I've written a matcher that provides the available default keyword
> arguments for the most recent open call; check below for a snapshot of
> interactive usage. It's not perfect (e.g. it cannot handle builtins), but
> I think it's adequate for most cases.

Sounds good ! I like it very much :o)

> I just subscribed to the list, so I have two questions on integrating new
> features: - What's the procedure for adding a new feature to the official
> release (of course if is deemed good, original and useful enough) ?
> - If for any reason it can't make it to the official release, what's the
> suggested way to integrate it in my own copy ? Currently I simply hacked
> iplib.py, but I wonder if there's a more elegant way to add new
> functionality.

Well, I think that Fernando will add this feature !

But it is possible to use the (recent) hook for matchers to implement yours. 
Have a look here:

    http://www.scipy.org/wikis/featurerequests/IPython

You can add new matchers using the set_custom_completer() method of the __IP 
object.

You need IPython 0.6.13.

PS : I would like to try it; could you send me the code of you matcher ?

-- 
   Fr?d?ric



From gsakkis at eden.rutgers.edu  Wed Apr 20 13:41:27 2005
From: gsakkis at eden.rutgers.edu (George Sakkis)
Date: Wed, 20 Apr 2005 13:41:27 -0400 (EDT)
Subject: [IPython-dev] Default parameter completer
In-Reply-To: <200504200822.20445.mantegazza@ill.fr>
References: <61524.68.197.31.58.1113973196.squirrel@webmail.eden.rutgers.edu>
	<200504200822.20445.mantegazza@ill.fr>
Message-ID: <63851.68.197.31.58.1114018887.squirrel@webmail.eden.rutgers.edu>

Hi Fr?d?ric,

> But it is possible to use the (recent) hook for matchers to implement yours.
> Have a look here:
>
>     http://www.scipy.org/wikis/featurerequests/IPython
>
> You can add new matchers using the set_custom_completer() method of the __IP
> object.
>
> You need IPython 0.6.13.

Nice, that's much better than bloating the iplib.py.

> PS : I would like to try it; could you send me the code of you matcher ?
>
> --
>    Fr?d?ric

I send it attached to the list for feedback.

Cheers,
George
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: defaultmatcher.py
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20050420/e7d1b423/attachment.ksh>