From mantegazza at ill.fr Tue May 3 03:37:44 2005 From: mantegazza at ill.fr (=?iso-8859-15?q?Fr=E9d=E9ric_Mantegazza?=) Date: Tue, 3 May 2005 09:37:44 +0200 Subject: [IPython-dev] Default parameter completer In-Reply-To: <63851.68.197.31.58.1114018887.squirrel@webmail.eden.rutgers.edu> References: <61524.68.197.31.58.1113973196.squirrel@webmail.eden.rutgers.edu> <200504200822.20445.mantegazza@ill.fr> <63851.68.197.31.58.1114018887.squirrel@webmail.eden.rutgers.edu> Message-ID: <200505030937.44645.mantegazza@ill.fr> Le Mercredi 20 Avril 2005 19:41, George Sakkis a ?crit : > > PS : I would like to try it; could you send me the code of you matcher > > I send it attached to the list for feedback. I tried you completer: very nice ! I will try to make it handle Pyro remote objects parameters, and I think I will integrate it in our app (hope it is GPL ?). Great work ! -- Fr?d?ric From gsakkis at eden.rutgers.edu Tue May 3 12:38:36 2005 From: gsakkis at eden.rutgers.edu (George Sakkis) Date: Tue, 3 May 2005 12:38:36 -0400 (EDT) Subject: [IPython-dev] Default parameter completer In-Reply-To: <200505030937.44645.mantegazza@ill.fr> References: <61524.68.197.31.58.1113973196.squirrel@webmail.eden.rutgers.edu> <63851.68.197.31.58.1114018887.squirrel@webmail.eden.rutgers.edu> <200505030937.44645.mantegazza@ill.fr> Message-ID: > Le Mercredi 20 Avril 2005 19:41, George Sakkis a ?crit : > > > > PS : I would like to try it; could you send me the code of you matcher > > > > I send it attached to the list for feedback. > > I tried you completer: very nice ! > > I will try to make it handle Pyro remote objects parameters, and I think I > will integrate it in our app (hope it is GPL ?). > > Great work ! > > -- > Fr?d?ric Thanks, I'll be glad if it gets included in the next release ! No problem with licencing, it's BSD like IPython. Regards, George From Fernando.Perez at colorado.edu Tue May 3 14:04:11 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Tue, 03 May 2005 12:04:11 -0600 Subject: [IPython-dev] Default parameter completer In-Reply-To: References: <61524.68.197.31.58.1113973196.squirrel@webmail.eden.rutgers.edu> <63851.68.197.31.58.1114018887.squirrel@webmail.eden.rutgers.edu> <200505030937.44645.mantegazza@ill.fr> Message-ID: <4277BD1B.4060309@colorado.edu> George Sakkis wrote: > Thanks, I'll be glad if it gets included in the next release ! No > problem with licencing, it's BSD like IPython. There will indeed be a .14 release because of a few bugs reported in the last 2 weeks, so I'll play with this and see if I can toss it in. Thanks for the code in any regard! Best, f From Fernando.Perez at colorado.edu Fri May 13 16:30:45 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Fri, 13 May 2005 14:30:45 -0600 Subject: [IPython-dev] Default parameter completer In-Reply-To: <63851.68.197.31.58.1114018887.squirrel@webmail.eden.rutgers.edu> References: <61524.68.197.31.58.1113973196.squirrel@webmail.eden.rutgers.edu> <200504200822.20445.mantegazza@ill.fr> <63851.68.197.31.58.1114018887.squirrel@webmail.eden.rutgers.edu> Message-ID: <42850E75.208@colorado.edu> George Sakkis wrote: > 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. Thanks for this, it looks very nice. Since I'll have to release a .14 with a number of fixes reported over the last few weeks, I added your patch as well, so it will be available in 0.6.14 by default. Regards, f From Fernando.Perez at colorado.edu Fri May 13 16:41:28 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Fri, 13 May 2005 14:41:28 -0600 Subject: [IPython-dev] Towards IPython 1.0, the famous big cleanup In-Reply-To: <200504151319.57796.mantegazza@ill.fr> References: <425EFA6C.30701@colorado.edu> <200504151319.57796.mantegazza@ill.fr> Message-ID: <428510F8.6070503@colorado.edu> Fr?d?ric Mantegazza wrote: > 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. I'd like to thank you for this comment. It's always very nice to hear from users that one's work is actually providing something good for them (it's far more common to hear when things break). I greatly appreciate it. And your feedback has been tremendously useful to me as well, it will give me clear directions for certain parts of the rework (starting as soon as I get my laptop back from the shop and I can release the bugfix .14 to wrap up). Best, f ps Frederic - sorry I never made it to Grenoble, my schedule turned out to be pretty crazy. Next time :) From Fernando.Perez at colorado.edu Fri May 13 16:49:15 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Fri, 13 May 2005 14:49:15 -0600 Subject: [IPython-dev] Towards IPython 1.0, the famous big cleanup In-Reply-To: <1113933927.11621.2.camel@localhost.localdomain> References: <425EFA6C.30701@colorado.edu> <1113584273.10208.18.camel@localhost.localdomain> <42600793.5070306@colorado.edu> <1113933927.11621.2.camel@localhost.localdomain> Message-ID: <428512CB.2060600@colorado.edu> Ville Vainio wrote: > 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.). Well, I still think it's worth making them special and isolated, for a number of reasons: - I don't want to pollute the user's namespace with these names. Currently you can do: In [11]: ls e*py error.py* err.py exit2.py* exit.py* In [12]: ls=1 In [13]: ls Out[13]: 1 In [14]: del ls In [15]: ls e*py error.py* err.py exit2.py* exit.py* This becomes impossible if you stuff them into the users' namespace. - Currently, %who shows you a clean namespace when you start, without a zillion aliases/magics. Do you really want to wade through a list of 3000 aliases every time you want to see what variables you've defined? - Magics behave like command-line utilities: --switch for options, whitespace separating arguments. I want to make it even easier to write new magics by exposing the option-handling machinery. This is part of what makes them convenient to use, since there's a lot less typing of commas, parens and quotes. For these reasons, and a 'gut' feeling that I'm right, I think it really does make sense to have a special system to handle these. But keep the debate coming, since now I'm really starting to work on this stuff, it's time to hammer out what the best decision is for the long run, and I'm willing to change my mind if a good argument is made. Best, f From vivainio at kolumbus.fi Sun May 15 10:50:16 2005 From: vivainio at kolumbus.fi (Ville Vainio) Date: Sun, 15 May 2005 17:50:16 +0300 Subject: [IPython-dev] Towards IPython 1.0, the famous big cleanup In-Reply-To: <428512CB.2060600@colorado.edu> References: <425EFA6C.30701@colorado.edu> <1113584273.10208.18.camel@localhost.localdomain> <42600793.5070306@colorado.edu> <1113933927.11621.2.camel@localhost.localdomain> <428512CB.2060600@colorado.edu> Message-ID: <1116168616.13576.9.camel@localhost.localdomain> On Fri, 2005-05-13 at 14:49 -0600, Fernando Perez wrote: > > 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.). > > Well, I still think it's worth making them special and isolated, for a number > of reasons: > > - I don't want to pollute the user's namespace with these names. Currently Perhaps different kinds of callables (magics, aliases, etc.) could be put in different modules, and the interactive prompt would just do a search of a list of modules in a configurable order when the command starts with a name that is not immediately visible. > - Currently, %who shows you a clean namespace when you start, without a > zillion aliases/magics. Do you really want to wade through a list of 3000 > aliases every time you want to see what variables you've defined? (covored by modules). > > - Magics behave like command-line utilities: --switch for options, whitespace > separating arguments. I want to make it even easier to write new magics by > exposing the option-handling machinery. This is part of what makes them > convenient to use, since there's a lot less typing of commas, parens and quotes. Solved by adding meta-information to the actual callables on how to pass the command line to the callable. A "magic" is just a callable that takes one argument, a string. It doesn't need to be any more special than that. In the module it could be minimally declared as @ipy_magic def magickstuff(s): ... and the ipy_magic decorator injects the necessary machinery to mangle the command line before the actual function receives it. From Fernando.Perez at colorado.edu Sun May 15 20:08:07 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Sun, 15 May 2005 18:08:07 -0600 Subject: [IPython-dev] Towards IPython 1.0, the famous big cleanup In-Reply-To: <1116168616.13576.9.camel@localhost.localdomain> References: <425EFA6C.30701@colorado.edu> <1113584273.10208.18.camel@localhost.localdomain> <42600793.5070306@colorado.edu> <1113933927.11621.2.camel@localhost.localdomain> <428512CB.2060600@colorado.edu> <1116168616.13576.9.camel@localhost.localdomain> Message-ID: <66ce8b6da2446f51031ace227c2464d1@colorado.edu> On May 15, 2005, at 8:50 AM, Ville Vainio wrote: > On Fri, 2005-05-13 at 14:49 -0600, Fernando Perez wrote: > >>> 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.). >> >> Well, I still think it's worth making them special and isolated, for >> a number >> of reasons: >> >> - I don't want to pollute the user's namespace with these names. >> Currently > > Perhaps different kinds of callables (magics, aliases, etc.) could be > put in different modules, and the interactive prompt would just do a > search of a list of modules in a configurable order when the command > starts with a name that is not immediately visible. [...] and by now you've basically described the system I have in mind :) Yes, there's the need for a table of names per type of special callable, some escaping mechanism for explicit disambiguation (at least for magics), and a bit of extra metadata here and there (command line args, how to access ipython itself, etc.) I _will_ do away with all the funny name mangling, and try to reuse as much of the same structure as possible for magics, aliases, etc. Cheers, f From vivainio at kolumbus.fi Mon May 16 14:07:55 2005 From: vivainio at kolumbus.fi (Ville Vainio) Date: Mon, 16 May 2005 21:07:55 +0300 Subject: [IPython-dev] Towards IPython 1.0, the famous big cleanup In-Reply-To: <66ce8b6da2446f51031ace227c2464d1@colorado.edu> References: <425EFA6C.30701@colorado.edu> <1113584273.10208.18.camel@localhost.localdomain> <42600793.5070306@colorado.edu> <1113933927.11621.2.camel@localhost.localdomain> <428512CB.2060600@colorado.edu> <1116168616.13576.9.camel@localhost.localdomain> <66ce8b6da2446f51031ace227c2464d1@colorado.edu> Message-ID: <1116266875.11490.5.camel@localhost.localdomain> On Sun, 2005-05-15 at 18:08 -0600, Fernando Perez wrote: > Yes, there's the need for a table of names per type of special > callable, some escaping mechanism for explicit disambiguation (at least > for magics), and a bit of extra metadata here and there (command line > args, how to access ipython itself, etc.) Why is the table needed? Is there an advantage over using good old-fashioned modules for this? Considering that there will be no name-mangling or anything... > I _will_ do away with all the funny name mangling, and try to reuse as > much of the same structure as possible for magics, aliases, etc. It would also be nice to be able to add new types of callables instead of the old magics and aliases, if only for experimentation with new features. Allowing to attach to the callables an user-specifiable object that does the preprocessing will achieve this. Of course a callable that takes the whole line can choose to do anything it wants, but the api could be extended to provide user-configurable argument completion etc... From Fernando.Perez at colorado.edu Mon May 16 14:17:06 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Mon, 16 May 2005 12:17:06 -0600 Subject: [IPython-dev] Towards IPython 1.0, the famous big cleanup In-Reply-To: <1116266875.11490.5.camel@localhost.localdomain> References: <425EFA6C.30701@colorado.edu> <1113584273.10208.18.camel@localhost.localdomain> <42600793.5070306@colorado.edu> <1113933927.11621.2.camel@localhost.localdomain> <428512CB.2060600@colorado.edu> <1116168616.13576.9.camel@localhost.localdomain> <66ce8b6da2446f51031ace227c2464d1@colorado.edu> <1116266875.11490.5.camel@localhost.localdomain> Message-ID: <4288E3A2.30801@colorado.edu> Ville Vainio wrote: > On Sun, 2005-05-15 at 18:08 -0600, Fernando Perez wrote: > > >>Yes, there's the need for a table of names per type of special >>callable, some escaping mechanism for explicit disambiguation (at least >>for magics), and a bit of extra metadata here and there (command line >>args, how to access ipython itself, etc.) > > > Why is the table needed? Is there an advantage over using good > old-fashioned modules for this? Considering that there will be no > name-mangling or anything... Well, a 'table' is a good old-fashioned dict, so it does have nostalgia value as well :) If I stick all that into a module and statically load that, how do I allow users to define their own, add them at runtime, load them via profiles, etc? It seems far easier to expose a single make_magic() function (or some similar simple API) which takes care of stuffing whatever is needed into a dict. Keep in mind that finding all these things has to be done on _every_ line of user input in order to match things not recognized as vars before throwing an exception. I can't think of any better data structure than a dict for this kind of efficient runtime search (esp. because the C implementation of dicts has a bunch of nifty fastpaths for string-keyed dicts, which mean this approach will work fast and clean). I think we're basically saying the same thing (or almost)... I'm just thinking of a particular implementation strategy which seems simple to the user, yet provides the efficiency needed for this component. Cheers, f From vivainio at kolumbus.fi Mon May 16 17:12:38 2005 From: vivainio at kolumbus.fi (Ville Vainio) Date: Tue, 17 May 2005 00:12:38 +0300 Subject: [IPython-dev] Towards IPython 1.0, the famous big cleanup In-Reply-To: <4288E3A2.30801@colorado.edu> References: <425EFA6C.30701@colorado.edu> <1113584273.10208.18.camel@localhost.localdomain> <42600793.5070306@colorado.edu> <1113933927.11621.2.camel@localhost.localdomain> <428512CB.2060600@colorado.edu> <1116168616.13576.9.camel@localhost.localdomain> <66ce8b6da2446f51031ace227c2464d1@colorado.edu> <1116266875.11490.5.camel@localhost.localdomain> <4288E3A2.30801@colorado.edu> Message-ID: <1116277958.11490.24.camel@localhost.localdomain> On Mon, 2005-05-16 at 12:17 -0600, Fernando Perez wrote: > If I stick all that into a module and statically load that, how do I allow > users to define their own, add them at runtime, load them via profiles, etc? > It seems far easier to expose a single make_magic() function (or some similar > simple API) which takes care of stuffing whatever is needed into a dict. make_magic can inject the name in the magic module in a similar fashion. > exception. I can't think of any better data structure than a dict for this > kind of efficient runtime search (esp. because the C implementation of dicts > has a bunch of nifty fastpaths for string-keyed dicts, which mean this > approach will work fast and clean). Module lookup is as fast because, well, it *is* a dict lookup, even if it happens via getattr :-). > I think we're basically saying the same thing (or almost)... I'm just > thinking of a particular implementation strategy which seems simple to the > user, yet provides the efficiency needed for this component. IMO it's more natural for the advanced user to be able to attach new modules to the search order. Modules have the advantage that they quite naturally have a 'name', which is an artificial addition to the dicts, if done. The naive user will know nothing about this, of course. He will just inject stuff into the 'user_magics' module through 'make_magic' function/decorator. But there would not be specific place where all the magics/aliases reside, just a bunch of modules in a list representing the search order (and subsequently precedence). For example it would be possible to "unload" a module this way by removing in from the search list, exposing names from subsequent modules that had a name collision before. It's my general hunch that the module approach might be simpler and more flexible/extensible in the long run. It's slightly slower if the search list is long, but that's going to be rare and it's a minimal performance it, considering that every global variable lookup is a dict lookup as well. From Fernando.Perez at colorado.edu Mon May 16 18:26:47 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Mon, 16 May 2005 16:26:47 -0600 Subject: [IPython-dev] Towards IPython 1.0, the famous big cleanup In-Reply-To: <1116277958.11490.24.camel@localhost.localdomain> References: <425EFA6C.30701@colorado.edu> <1113584273.10208.18.camel@localhost.localdomain> <42600793.5070306@colorado.edu> <1113933927.11621.2.camel@localhost.localdomain> <428512CB.2060600@colorado.edu> <1116168616.13576.9.camel@localhost.localdomain> <66ce8b6da2446f51031ace227c2464d1@colorado.edu> <1116266875.11490.5.camel@localhost.localdomain> <4288E3A2.30801@colorado.edu> <1116277958.11490.24.camel@localhost.localdomain> Message-ID: <42891E27.4070403@colorado.edu> Ville Vainio wrote: [...] Thanks for the feedback. When I get to doing the actual implementation, I'll go over this discussion again carefully, to make sure that we do get the best overall solution in place. And I'll pitch in again here on the list if I'm not 100% certain. In the end we may be splitting hairs, but I want to make sure that we do split them in the best possible way, for the long-term good of the project :) Regards, f From vivainio at kolumbus.fi Tue May 17 01:27:50 2005 From: vivainio at kolumbus.fi (Ville Vainio) Date: Tue, 17 May 2005 08:27:50 +0300 Subject: [IPython-dev] Towards IPython 1.0, the famous big cleanup In-Reply-To: <42891E27.4070403@colorado.edu> References: <425EFA6C.30701@colorado.edu> <1113584273.10208.18.camel@localhost.localdomain> <42600793.5070306@colorado.edu> <1113933927.11621.2.camel@localhost.localdomain> <428512CB.2060600@colorado.edu> <1116168616.13576.9.camel@localhost.localdomain> <66ce8b6da2446f51031ace227c2464d1@colorado.edu> <1116266875.11490.5.camel@localhost.localdomain> <4288E3A2.30801@colorado.edu> <1116277958.11490.24.camel@localhost.localdomain> <42891E27.4070403@colorado.edu> Message-ID: <1116307670.9701.0.camel@localhost.localdomain> On Mon, 2005-05-16 at 16:26 -0600, Fernando Perez wrote: > not 100% certain. In the end we may be splitting hairs, but I want to make > sure that we do split them in the best possible way, for the long-term good of > the project :) Yep, now is the time to be neurotic about everything :-). From tom at livelogix.com Sun May 22 00:38:11 2005 From: tom at livelogix.com (Tom Locke) Date: Sun, 22 May 2005 10:08:11 +0530 Subject: [IPython-dev] Why does Debugger.Pdb inherit from bdb.Bdb, cmd.Cmd? In-Reply-To: <66ce8b6da2446f51031ace227c2464d1@colorado.edu> References: <425EFA6C.30701@colorado.edu> <1113584273.10208.18.camel@localhost.localdomain> <42600793.5070306@colorado.edu> <1113933927.11621.2.camel@localhost.localdomain> <428512CB.2060600@colorado.edu> <1116168616.13576.9.camel@localhost.localdomain> <66ce8b6da2446f51031ace227c2464d1@colorado.edu> Message-ID: <42900CB3.60709@livelogix.com> Hi, I'm writing a custom Python debugger. The base class will either be pdb.Pdb or IPython.Debugger.Pdb if that is available. I noticed that IPython .Pdb inherits from dbd.Bdb and cmd.Cmd directly, despite the fact that pdb.Pdb already does so. I don't understand why, so I just wanted to ask in case I'm missing something important. I realise Debugger.Pdb.__init__ cannot call pdb.Pdb.__init__ directly, as it needs to pass completekey=None to Cmd.__init__, but I don't see why it can't just have pdb.Pdb as its single base class. Am I missing something? Tom. From Fernando.Perez at colorado.edu Sun May 22 15:40:18 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Sun, 22 May 2005 13:40:18 -0600 Subject: [IPython-dev] Why does Debugger.Pdb inherit from bdb.Bdb, cmd.Cmd? In-Reply-To: <42900CB3.60709@livelogix.com> References: <425EFA6C.30701@colorado.edu> <1113584273.10208.18.camel@localhost.localdomain> <42600793.5070306@colorado.edu> <1113933927.11621.2.camel@localhost.localdomain> <428512CB.2060600@colorado.edu> <1116168616.13576.9.camel@localhost.localdomain> <66ce8b6da2446f51031ace227c2464d1@colorado.edu> <42900CB3.60709@livelogix.com> Message-ID: <4290E022.4090301@colorado.edu> Tom Locke wrote: > Hi, > > I'm writing a custom Python debugger. The base class will either be > pdb.Pdb or IPython.Debugger.Pdb if that is available. > > I noticed that IPython .Pdb inherits from dbd.Bdb and cmd.Cmd directly, > despite the fact that pdb.Pdb already does so. I don't understand why, > so I just wanted to ask in case I'm missing something important. > > I realise Debugger.Pdb.__init__ cannot call pdb.Pdb.__init__ directly, > as it needs to pass completekey=None to Cmd.__init__, but I don't see > why it can't just have pdb.Pdb as its single base class. > > Am I missing something? Nope, nothing. In fact, it was probably just carelessness on my part, I just fixed it to read: class Pdb(pdb.Pdb): """Modified Pdb class, does not load readline.""" and I can't see any ill effects. This will go into the .14 bugfix (a few days out) Thanks for pointing this out. Cheers, f From Fernando.Perez at colorado.edu Tue May 31 02:43:01 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Tue, 31 May 2005 00:43:01 -0600 Subject: [IPython-dev] [ANN] IPython 0.6.14. Message-ID: <429C0775.9020406@colorado.edu> Hi all, I've just made the 0.6.14 release of IPython, mostly to fix the inevitable bugs reported after the .13 one (though one big improvement sneaked by). 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. I'd like to add a special thanks to Denis Rivi?re, Yann Cointepas and Benjamin Thyreau for their hard work on the Qt improvements, and for their overall hospitality. Python really seems to have a remarkably friendly community, worldwide! Release notes ------------- 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. This is mainly a bugfix release, to clean up the problems reported in 0.6.13. As I said at the time, I intend to start new development now (more details on that in a separate email). As always, however, a few new goodies managed to sneak by. * A new -qthread option to support controlling Qt apps from within ipython, similar to what -gthread and -wthread do for GTK/WX. This was contributed by Denis Rivi?re , Yann Cointepas and Benjamin Thyreau . Many thanks to them! The lack of Qt support was a glaring omission of ipython's gui features, so I'm extremely happy to have their contribution. For those of you who may be matplotlib users as well, I should note that as of mpl 0.81 (the next release, or use current CVS), the -pylab option will also support interactive matplotlib use with the Qt backend. This is also thanks to work done by Denis, Yann and Benjamin against the matplotlib Qt backend, in conjunction with the IPython improvements. * New -e option to %run to suppress tracebacks from sys.exit() calls. This can be very useful to silence all the noise generated when running unittests from within ipython. * New ';' escape to autoquote a line without splitting: In [6]: ,foo a b c ------> foo("a", "b", "c") In [7]: ;foo a b c ------> foo("a b c") In the process, I fixed ',' quoting, which I'd broken in .13. * Fix -wthread to work with WXPython 2.6 (this also impacts matplotlib users who run the WX backend). * Added new matcher (it goes at the end of the priority list) to do tab-completion on named function arguments. Submitted by George Sakkis . See the thread at http://www.scipy.net/pipermail/ipython-dev/2005-April/000436.html for more details. * Various other fixes for obscure bugs, but all of which caused reported IPython crashes. Details in Changelog. Enjoy, and as usual please report any problems. Regards, Fernando. From Fernando.Perez at colorado.edu Tue May 31 03:04:28 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Tue, 31 May 2005 01:04:28 -0600 Subject: [IPython-dev] Life after .14... Message-ID: <429C0C7C.1000701@colorado.edu> Hi all, well, now that .14 is out the door with the accumulated bugfixes (more than I was expecting, to be honest) and the nice new Qt support, it's time to start doing core work on ipython. Since I know it's inevitable that new bugs will appear, when a 0.6.15 release is needed for bugfixing, I'll simply branch off the current CVS tag. That also means that anyone sending me patches should use the tag rel-0_6_14 to work on any patches you send me. Once work on that tag begins, I'll make a MAINT branch out of it. Btw, this is what i read up quickly about branches and tags in CVS, which I've never used before. If I'm screwing up on that front, please let me know right away. I will move the version number now to 0.9.0_cvs, to indicate that the trunk is now only for HIGHLY UNSTABLE DEVELOPMENT. Please, anyone who used to follow ipython CVS should stop doing so now, as I plan on breaking things left and right. As I'd mentioned before, since my resources are so limited, this means that 0.6.14 will be effectively the end of the road for the current ipython, bugfixes excepted. I will now spend all my time on the internal cleanup, and that means that for a while, no new features will go in unless someone sends me a 100% ready-to-go patch which applies cleanly against the .14 CVS tagged code. I think the current code is stable and functional enough that most people won't be affected by this in any way. But in order to effectively use ipython in new and more complex ways, cleaner internals are really needed. I hope that after the wait is over, it will have been worth it. Thanks to all who have used ipython so far or helped me in any way with it. Regards, Fernando From mantegazza at ill.fr Tue May 31 03:17:02 2005 From: mantegazza at ill.fr (=?iso-8859-15?q?Fr=E9d=E9ric_Mantegazza?=) Date: Tue, 31 May 2005 09:17:02 +0200 Subject: [IPython-dev] Life after .14... In-Reply-To: <429C0C7C.1000701@colorado.edu> References: <429C0C7C.1000701@colorado.edu> Message-ID: <200505310917.02874.mantegazza@ill.fr> Le Mardi 31 Mai 2005 09:04, Fernando Perez a ?crit : > to work on any patches you send me. Once work on that tag begins, I'll > make a MAINT branch out of it. Btw, this is what i read up quickly about > branches and tags in CVS, which I've never used before. If I'm screwing > up on that front, please let me know right away. I didn't use branches under CVS, so I can't help... But I think you should switch from CVS to Subversion for the big cleanup. SVN is much more powerfull, and maybe easier to use. For the common part, you use svn the same way you use cvs, so transition is very easy. And there are some tools to migrate an entire cvs project into svn one. It works very well (I used it on 3 or 4 big projects). Just an idea... -- Fr?d?ric From prabhu_r at users.sf.net Tue May 31 06:59:37 2005 From: prabhu_r at users.sf.net (Prabhu Ramachandran) Date: Tue, 31 May 2005 16:29:37 +0530 Subject: [IPython-dev] Life after .14... In-Reply-To: <200505310917.02874.mantegazza@ill.fr> References: <429C0C7C.1000701@colorado.edu> <200505310917.02874.mantegazza@ill.fr> Message-ID: <17052.17305.32371.136514@monster.linux.in> FM> But I think you should switch from CVS to Subversion for the FM> big cleanup.=20 SVN is much more powerfull, and maybe easier FM> to use. For the common part,=20 you use svn the same way you FM> use cvs, so transition is very easy. And there= =20 are some FM> tools to migrate an entire cvs project into svn one. It works FM> very= =20 well (I used it on 3 or 4 big projects). +10 :-) cheers, prabhu From hans_meine at gmx.net Tue May 31 07:22:54 2005 From: hans_meine at gmx.net (Hans Meine) Date: Tue, 31 May 2005 13:22:54 +0200 Subject: [IPython-dev] IPython and Qt?! Message-ID: <200505311322.54388.hans_meine@gmx.net> Hi everybody, I discovered IPython only recently. It's a real gem! :-) We developed our own Qt Python-terminal, but actually I think I could become more happy with concentrating on improving IPython instead. (Our GUI is quite a mess internally..) Our current solution actually runs the "internal" python interpreter in a separate process; now I am curious whether we can reach the same goal with a separate thread, too. I patch IPython/Shell.py to run a QApplication in a separate thread, and my first experiments were quite successful. Would you like to have a look at it and tell me whether there is a reason that Qt was not yet supported? One possible problem that I see is the following, quoted from http://doc.trolltech.com/3.3/threads.html "In Qt, one thread is always the GUI or event thread. This is the thread that creates a QApplication object and calls QApplication::exec(). This is also the initial thread that calls main() at program start. This thread is the only thread that is allowed to perform GUI operations, including generating and receiving events from the window system. Qt does not support creating QApplication and running the event loop (with QApplication::exec()) in a secondary thread. You must create the QApplication object and call QApplication::exec() from the main() function in your program. "Threads that wish to display data in a widget cannot modify the widget directly, so they must post an event to the widget using QApplication::postEvent(). The event will be delivered later on by the GUI thread." Now I wonder whether the commands I type in the ipython shell are executed in the right thread (the one running QApplication::exec(), resp. .exec_loop() in python)? I did not yet run into problems, but of course there could be timing problems that I have later? Ciao, / / /--/ / / ANS From hans_meine at gmx.net Tue May 31 08:45:23 2005 From: hans_meine at gmx.net (Hans Meine) Date: Tue, 31 May 2005 14:45:23 +0200 Subject: [IPython-dev] Preventing "Oops, IPython crashed" ? Message-ID: <200505311445.23247.hans_meine@gmx.net> Hi again, I forgot to ask this question, related to my Qt experiments: I loaded some experimental GUI code, and noticed that exceptions resulting from GUI actions result in this very verbose IPython traceback / bugreporting output. Is there a way to get a similar traceback to the one I get when calling functions manually from within IPython? Ciao, / / /--/ / / ANS From hans_meine at gmx.net Tue May 31 08:50:15 2005 From: hans_meine at gmx.net (Hans Meine) Date: Tue, 31 May 2005 14:50:15 +0200 Subject: [IPython-dev] IPython and Qt?! In-Reply-To: <200505311322.54388.hans_meine@gmx.net> References: <200505311322.54388.hans_meine@gmx.net> Message-ID: <200505311450.15353.hans_meine@gmx.net> On Tuesday 31 May 2005 13:22, Hans Meine wrote: > I patched IPython/Shell.py to run a QApplication in > a separate thread, and my first experiments were quite successful. > > Would you like to have a look at it [...] Of course, my intention was to post the patch... ;-) BTW: In case you're not familiar with Qt and don't have the python bindings installed yet, they're called PyQt and depend on sip. Ciao, / / /--/ / / ANS PS: Resent due to wrong sending address. -------------- next part -------------- A non-text attachment was scrubbed... Name: IPShellQt.diff Type: text/x-diff Size: 1601 bytes Desc: not available URL: From Fernando.Perez at colorado.edu Tue May 31 15:04:10 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Tue, 31 May 2005 13:04:10 -0600 Subject: [IPython-dev] IPython and Qt?! In-Reply-To: <200505311450.15353.hans_meine@gmx.net> References: <200505311322.54388.hans_meine@gmx.net> <200505311450.15353.hans_meine@gmx.net> Message-ID: <429CB52A.3060807@colorado.edu> Hans Meine wrote: > On Tuesday 31 May 2005 13:22, Hans Meine wrote: > >>I patched IPython/Shell.py to run a QApplication in >>a separate thread, and my first experiments were quite successful. >> >>Would you like to have a look at it [...] > > > Of course, my intention was to post the patch... ;-) > > BTW: In case you're not familiar with Qt and don't have the python bindings > installed yet, they're called PyQt and depend on sip. I love it when I get to use my little time machine :) Did you have a look at last night's (my time) announcement of ipython 0.6.14? The big new feature there is Qt support... Note that the Qt support in ipython wasn't written by me, but by a group of friends who are extremely experienced with Qt. I think they found out, after trying something like your patch, that it wasn't quite enough. In certain cases, things could still block. If you read the current Shell.py, you'll see that they play some special tricks with the timer to avoid deadlocks. Have a look at .14, and let me know if it doesn't do what you need... Best, f From Fernando.Perez at colorado.edu Tue May 31 15:10:25 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Tue, 31 May 2005 13:10:25 -0600 Subject: [IPython-dev] Preventing "Oops, IPython crashed" ? In-Reply-To: <200505311445.23247.hans_meine@gmx.net> References: <200505311445.23247.hans_meine@gmx.net> Message-ID: <429CB6A1.6010604@colorado.edu> Hans Meine wrote: > Hi again, > > I forgot to ask this question, related to my Qt experiments: I loaded some > experimental GUI code, and noticed that exceptions resulting from GUI actions > result in this very verbose IPython traceback / bugreporting output. > > Is there a way to get a similar traceback to the one I get when calling > functions manually from within IPython? Not that I know. Unfortunately, exceptions raised in a different thread propagate all the way through to sys.excepthook, which is the ipython crash handler. And I don't know of a way at that point of identifying whether the exception was caused by ipython code or by user code, so the crash handler just does its job and prints that monster traceback. This really annoys me a lot, but from all the googling and reading of maling lists which I did, it seemed to me that cross-thread exception handling in python was just somewhat limited. I'd love to learn of a way around this problem, though, so by all means let me know if you are aware of a viable solution. There is a workaround: you can manually reset sys.excepthook to the ipython normal exception handler: sys.excepthook = __IPYTHON__.excepthook By running this line, you lose the real crash handler though, so if ipython proper crashes, I will get a LOT less debug information. Caveat emptor. regards, f From Fernando.Perez at colorado.edu Tue May 31 15:14:41 2005 From: Fernando.Perez at colorado.edu (Fernando Perez) Date: Tue, 31 May 2005 13:14:41 -0600 Subject: [IPython-dev] Life after .14... In-Reply-To: <17052.17305.32371.136514@monster.linux.in> References: <429C0C7C.1000701@colorado.edu> <200505310917.02874.mantegazza@ill.fr> <17052.17305.32371.136514@monster.linux.in> Message-ID: <429CB7A1.7070802@colorado.edu> Prabhu Ramachandran wrote: > FM> But I think you should switch from CVS to Subversion for the > FM> big cleanup.=20 SVN is much more powerfull, and maybe easier > FM> to use. For the common part,=20 you use svn the same way you > FM> use cvs, so transition is very easy. And there= =20 are some > FM> tools to migrate an entire cvs project into svn one. It works > FM> very= =20 well (I used it on 3 or 4 big projects). > > +10 :-) Yes, thanks to both for the reminder. For whatever odd reason (late night posting with brain off, probably), svn fell off my mind last night. But I've also been using it in other things, and like it a lot. This is indeed a cleaner solution, and it also means that CVS can stay in place for the post-.14 bugfixes without branching, while all new development takes place on SVN. That way, I don't even have to learn about CVS branching, which is a good thing :) So in summary, anyone who wants to send me a patch can do so against CVS, and once svn is up and running I'll post the info on the list. I'll do all new work on SVN. Thanks again, f