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: 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/ NameError: name 'cd' is not defined In [16]:for i in xrange(3): ....: %cd /tmp ------------------------------------------------------------ File "", 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/ NameError: name 'pr' is not defined In [18]:for i in range(3): ....: pr a1 ------------------------------------------------------------ File "", line 2 pr a1 ^ SyntaxError: invalid syntax In [18]:for i in range(3): ....: %pr a1 ------------------------------------------------------------ File "", 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: