From walter at livinglogic.de  Tue May  1 08:35:12 2007
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Tue, 01 May 2007 14:35:12 +0200
Subject: [IPython-dev] IPython in the cheeseshop
Message-ID: <46373400.6090208@livinglogic.de>

There are two entries in the cheeseshop for IPython:

http://cheeseshop.python.org/pypi/IPython (for 0.5.0)
http://cheeseshop.python.org/pypi/ipython (for 0.8.0)

Shouldn't the first one be deleted?

Servus,
    Walter



From fperez.net at gmail.com  Tue May  1 23:52:00 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 1 May 2007 21:52:00 -0600
Subject: [IPython-dev] IPython in the cheeseshop
In-Reply-To: <46373400.6090208@livinglogic.de>
References: <46373400.6090208@livinglogic.de>
Message-ID: <db6b5ecc0705012052v643f7995ne5fdd3fe9d45db@mail.gmail.com>

On 5/1/07, Walter D?rwald <walter at livinglogic.de> wrote:
> There are two entries in the cheeseshop for IPython:
>
> http://cheeseshop.python.org/pypi/IPython (for 0.5.0)
> http://cheeseshop.python.org/pypi/ipython (for 0.8.0)
>
> Shouldn't the first one be deleted?

Yup.  Unfortunately, I don't own the cheeseshop package for it, it's
listed as belonging to Rod Holland.  I don't recall having any contact
info for him.

Rod, if you are on this list, could you please delete that package?

Cheers,

f


From fperez.net at gmail.com  Tue May  1 23:53:00 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 1 May 2007 21:53:00 -0600
Subject: [IPython-dev] Better reporting for non-ascii home dir names
In-Reply-To: <46cb515a0704300527i352bc04cuf90df73ba4950f4d@mail.gmail.com>
References: <46cb515a0704300414k3e5057fch20f2c22ab0ba32ed@mail.gmail.com>
	<20070430115911.GH3761@mentat.za.net>
	<46cb515a0704300506i6fad5695g92b0ce24aded63eb@mail.gmail.com>
	<20070430121815.GI3761@mentat.za.net>
	<46cb515a0704300527i352bc04cuf90df73ba4950f4d@mail.gmail.com>
Message-ID: <db6b5ecc0705012053j13e48f75i6a9d534f1e77a6b5@mail.gmail.com>

Hey guys,

I haven't followed this one in detail, so I'm just asking: should we
wait further for 0.8.1 due to this?

Cheers,

f


From fperez.net at gmail.com  Tue May  1 23:53:00 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 1 May 2007 21:53:00 -0600
Subject: [IPython-dev] Better reporting for non-ascii home dir names
In-Reply-To: <46cb515a0704300527i352bc04cuf90df73ba4950f4d@mail.gmail.com>
References: <46cb515a0704300414k3e5057fch20f2c22ab0ba32ed@mail.gmail.com>
	<20070430115911.GH3761@mentat.za.net>
	<46cb515a0704300506i6fad5695g92b0ce24aded63eb@mail.gmail.com>
	<20070430121815.GI3761@mentat.za.net>
	<46cb515a0704300527i352bc04cuf90df73ba4950f4d@mail.gmail.com>
Message-ID: <db6b5ecc0705012053j13e48f75i6a9d534f1e77a6b5@mail.gmail.com>

Hey guys,

I haven't followed this one in detail, so I'm just asking: should we
wait further for 0.8.1 due to this?

Cheers,

f


From fperez.net at gmail.com  Tue May  1 23:56:54 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 1 May 2007 21:56:54 -0600
Subject: [IPython-dev] [IPython-user] Testers requested - 0.7.4.rc1,
	with async cross-thread exceptions
In-Reply-To: <20070424192234.3bd68684@linux.fr>
References: <db6b5ecc0704042313l6b9cbbf8x2d22837d20725284@mail.gmail.com>
	<20070407141843.0cad6f48@linux.fr>
	<db6b5ecc0704071441p2a344f77xdf03be17ad09ec7a@mail.gmail.com>
	<20070410192628.075b873e@linux.fr> <20070424192234.3bd68684@linux.fr>
Message-ID: <db6b5ecc0705012056l2ec326e6q4df0ed30ef65594e@mail.gmail.com>

On 4/24/07, Nicolas Pernetty <nicopernetty at yahoo.fr> wrote:
> Have you had any luck with this problem and could I be of any help ?

No, not really (no luck).  Since the problem isn't really reproducible
under Linux, I'd suggest creating a ticket for it on the tracker,
assigned to Ville or Jorgen.  Given how they are win32 users, they may
actually be able to reproduce it and track what's going on, and at
least that way it won't get forgotten just in my inbox.

In the meantime, keep your local workaround :)

Cheers,

f


From vivainio at gmail.com  Wed May  2 01:40:34 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 2 May 2007 07:40:34 +0200
Subject: [IPython-dev] Better reporting for non-ascii home dir names
In-Reply-To: <db6b5ecc0705012053j13e48f75i6a9d534f1e77a6b5@mail.gmail.com>
References: <46cb515a0704300414k3e5057fch20f2c22ab0ba32ed@mail.gmail.com>
	<20070430115911.GH3761@mentat.za.net>
	<46cb515a0704300506i6fad5695g92b0ce24aded63eb@mail.gmail.com>
	<20070430121815.GI3761@mentat.za.net>
	<46cb515a0704300527i352bc04cuf90df73ba4950f4d@mail.gmail.com>
	<db6b5ecc0705012053j13e48f75i6a9d534f1e77a6b5@mail.gmail.com>
Message-ID: <46cb515a0705012240l3fe6e763n20b9a207775b4c49@mail.gmail.com>

On 5/2/07, Fernando Perez <fperez.net at gmail.com> wrote:

> Hey guys,
>
> I haven't followed this one in detail, so I'm just asking: should we
> wait further for 0.8.1 due to this?

Nope. The current fix is ok for 0.8.1

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From vivainio at gmail.com  Wed May  2 01:40:34 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 2 May 2007 07:40:34 +0200
Subject: [IPython-dev] Better reporting for non-ascii home dir names
In-Reply-To: <db6b5ecc0705012053j13e48f75i6a9d534f1e77a6b5@mail.gmail.com>
References: <46cb515a0704300414k3e5057fch20f2c22ab0ba32ed@mail.gmail.com>
	<20070430115911.GH3761@mentat.za.net>
	<46cb515a0704300506i6fad5695g92b0ce24aded63eb@mail.gmail.com>
	<20070430121815.GI3761@mentat.za.net>
	<46cb515a0704300527i352bc04cuf90df73ba4950f4d@mail.gmail.com>
	<db6b5ecc0705012053j13e48f75i6a9d534f1e77a6b5@mail.gmail.com>
Message-ID: <46cb515a0705012240l3fe6e763n20b9a207775b4c49@mail.gmail.com>

On 5/2/07, Fernando Perez <fperez.net at gmail.com> wrote:

> Hey guys,
>
> I haven't followed this one in detail, so I'm just asking: should we
> wait further for 0.8.1 due to this?

Nope. The current fix is ok for 0.8.1

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From fperez.net at gmail.com  Wed May  2 02:37:24 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 2 May 2007 00:37:24 -0600
Subject: [IPython-dev] Better reporting for non-ascii home dir names
In-Reply-To: <46cb515a0705012240l3fe6e763n20b9a207775b4c49@mail.gmail.com>
References: <46cb515a0704300414k3e5057fch20f2c22ab0ba32ed@mail.gmail.com>
	<20070430115911.GH3761@mentat.za.net>
	<46cb515a0704300506i6fad5695g92b0ce24aded63eb@mail.gmail.com>
	<20070430121815.GI3761@mentat.za.net>
	<46cb515a0704300527i352bc04cuf90df73ba4950f4d@mail.gmail.com>
	<db6b5ecc0705012053j13e48f75i6a9d534f1e77a6b5@mail.gmail.com>
	<46cb515a0705012240l3fe6e763n20b9a207775b4c49@mail.gmail.com>
Message-ID: <db6b5ecc0705012337x5414efddkada8395a19b8d809@mail.gmail.com>

On 5/1/07, Ville M. Vainio <vivainio at gmail.com> wrote:
> On 5/2/07, Fernando Perez <fperez.net at gmail.com> wrote:
>
> > Hey guys,
> >
> > I haven't followed this one in detail, so I'm just asking: should we
> > wait further for 0.8.1 due to this?
>
> Nope. The current fix is ok for 0.8.1

OK.  What about these new tickets, do we leave them for post-0.8.1?

http://projects.scipy.org/ipython/ipython/ticket/142
http://projects.scipy.org/ipython/ipython/ticket/144

Now that we started moving core ipython code into the saw branch, I
really won't touch this much at all, so it's your call...

Cheers,

f

ps - There's a few other open ones I can deal with.


From fperez.net at gmail.com  Wed May  2 02:37:24 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 2 May 2007 00:37:24 -0600
Subject: [IPython-dev] Better reporting for non-ascii home dir names
In-Reply-To: <46cb515a0705012240l3fe6e763n20b9a207775b4c49@mail.gmail.com>
References: <46cb515a0704300414k3e5057fch20f2c22ab0ba32ed@mail.gmail.com>
	<20070430115911.GH3761@mentat.za.net>
	<46cb515a0704300506i6fad5695g92b0ce24aded63eb@mail.gmail.com>
	<20070430121815.GI3761@mentat.za.net>
	<46cb515a0704300527i352bc04cuf90df73ba4950f4d@mail.gmail.com>
	<db6b5ecc0705012053j13e48f75i6a9d534f1e77a6b5@mail.gmail.com>
	<46cb515a0705012240l3fe6e763n20b9a207775b4c49@mail.gmail.com>
Message-ID: <db6b5ecc0705012337x5414efddkada8395a19b8d809@mail.gmail.com>

On 5/1/07, Ville M. Vainio <vivainio at gmail.com> wrote:
> On 5/2/07, Fernando Perez <fperez.net at gmail.com> wrote:
>
> > Hey guys,
> >
> > I haven't followed this one in detail, so I'm just asking: should we
> > wait further for 0.8.1 due to this?
>
> Nope. The current fix is ok for 0.8.1

OK.  What about these new tickets, do we leave them for post-0.8.1?

http://projects.scipy.org/ipython/ipython/ticket/142
http://projects.scipy.org/ipython/ipython/ticket/144

Now that we started moving core ipython code into the saw branch, I
really won't touch this much at all, so it's your call...

Cheers,

f

ps - There's a few other open ones I can deal with.


From fperez.net at gmail.com  Wed May  2 02:48:20 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 2 May 2007 00:48:20 -0600
Subject: [IPython-dev] Better reporting for non-ascii home dir names
In-Reply-To: <db6b5ecc0705012337x5414efddkada8395a19b8d809@mail.gmail.com>
References: <46cb515a0704300414k3e5057fch20f2c22ab0ba32ed@mail.gmail.com>
	<20070430115911.GH3761@mentat.za.net>
	<46cb515a0704300506i6fad5695g92b0ce24aded63eb@mail.gmail.com>
	<20070430121815.GI3761@mentat.za.net>
	<46cb515a0704300527i352bc04cuf90df73ba4950f4d@mail.gmail.com>
	<db6b5ecc0705012053j13e48f75i6a9d534f1e77a6b5@mail.gmail.com>
	<46cb515a0705012240l3fe6e763n20b9a207775b4c49@mail.gmail.com>
	<db6b5ecc0705012337x5414efddkada8395a19b8d809@mail.gmail.com>
Message-ID: <db6b5ecc0705012348k2a42d772t1e6f82f67d717f14@mail.gmail.com>

On 5/2/07, Fernando Perez <fperez.net at gmail.com> wrote:

> OK.  What about these new tickets, do we leave them for post-0.8.1?
>
> http://projects.scipy.org/ipython/ipython/ticket/142

I just closed this one:

> http://projects.scipy.org/ipython/ipython/ticket/144

142 remains...

Cheers,

f


From fperez.net at gmail.com  Wed May  2 02:48:20 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 2 May 2007 00:48:20 -0600
Subject: [IPython-dev] Better reporting for non-ascii home dir names
In-Reply-To: <db6b5ecc0705012337x5414efddkada8395a19b8d809@mail.gmail.com>
References: <46cb515a0704300414k3e5057fch20f2c22ab0ba32ed@mail.gmail.com>
	<20070430115911.GH3761@mentat.za.net>
	<46cb515a0704300506i6fad5695g92b0ce24aded63eb@mail.gmail.com>
	<20070430121815.GI3761@mentat.za.net>
	<46cb515a0704300527i352bc04cuf90df73ba4950f4d@mail.gmail.com>
	<db6b5ecc0705012053j13e48f75i6a9d534f1e77a6b5@mail.gmail.com>
	<46cb515a0705012240l3fe6e763n20b9a207775b4c49@mail.gmail.com>
	<db6b5ecc0705012337x5414efddkada8395a19b8d809@mail.gmail.com>
Message-ID: <db6b5ecc0705012348k2a42d772t1e6f82f67d717f14@mail.gmail.com>

On 5/2/07, Fernando Perez <fperez.net at gmail.com> wrote:

> OK.  What about these new tickets, do we leave them for post-0.8.1?
>
> http://projects.scipy.org/ipython/ipython/ticket/142

I just closed this one:

> http://projects.scipy.org/ipython/ipython/ticket/144

142 remains...

Cheers,

f


From walter at livinglogic.de  Wed May  2 03:26:40 2007
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Wed, 02 May 2007 09:26:40 +0200
Subject: [IPython-dev] IPython in the cheeseshop
In-Reply-To: <db6b5ecc0705012052v643f7995ne5fdd3fe9d45db@mail.gmail.com>
References: <46373400.6090208@livinglogic.de>
	<db6b5ecc0705012052v643f7995ne5fdd3fe9d45db@mail.gmail.com>
Message-ID: <46383D30.2090205@livinglogic.de>

Fernando Perez wrote:
> On 5/1/07, Walter D?rwald <walter at livinglogic.de> wrote:
>> There are two entries in the cheeseshop for IPython:
>>
>> http://cheeseshop.python.org/pypi/IPython (for 0.5.0)
>> http://cheeseshop.python.org/pypi/ipython (for 0.8.0)
>>
>> Shouldn't the first one be deleted?
> 
> Yup.  Unfortunately, I don't own the cheeseshop package for it, it's
> listed as belonging to Rod Holland.  I don't recall having any contact
> info for him.
> 
> Rod, if you are on this list, could you please delete that package?

If all else fails, we could always try to convince the cheeseshop 
maintainers to delete the old entry.

Servus,
    Walter


From list-ener at strank.info  Wed May  2 08:13:34 2007
From: list-ener at strank.info (Stefan Rank)
Date: Wed, 02 May 2007 14:13:34 +0200
Subject: [IPython-dev] ipython embedded in twisted, no threads
In-Reply-To: <46266553.2020602@bostream.nu>
References: <4623183F.4070807@strank.info>
	<4623BD67.4010007@bostream.nu>	<4623F754.9060706@strank.info>
	<46266553.2020602@bostream.nu>
Message-ID: <4638806E.4090300@strank.info>

on 18.04.2007 20:37 J?rgen Stenarson said the following:
> Hi Stefan,
> 
> I have done some more experimenting. And now I think I have something 
> resembling what you were after. If you replace the emacs.py file in 
> pyreadline/modes/emacs.py with the attached version. Then running the 
> async_test.py should give you a prompt where you can type away and at 
> the same time the window title has a counter that is increased every 
> second. Make sure you have a recent update from svn before replacing 
> emacs.py.

Hi J?rgen,

attached is a small testfile using your modified emacs.py.
Works as expected.
I added some monkeypatching to expose a GNU-readline-callback-api-alike 
as module level functions.
If these look good to you, it would be great if you could incorporate 
them into pyreadline.

I am not sure about handling of Ctrl-C/D... but for users of the 
callback interface, a keyboard interrupt will typically occur outside of 
readline code, so it's the concern of the calling code (which is waiting 
for events) anyway.
I will also try to expose the GNU readline callback variant on Linux 
using ctypes and see how it behaves.
(Next step towards world domination: Get this and pyreadline into the 
Python standard library... ;-)

As for twisted: to use this callback interface I am subclassing 
twisted.internet.stdio.StandardIO (as ReadlineIO), and it sort of works 
already.
Currently, I am not really sure about when and where to add '\r\n' (or 
even '\n'? )... to the prompt? to printing of the result? ... but that 
is a minor problem.

cheers,
stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: readlinecallbacktest.py
Type: text/x-python
Size: 3388 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20070502/ce3882e4/attachment.py>

From Glen.Mabey at swri.org  Wed May  2 10:11:07 2007
From: Glen.Mabey at swri.org (Glen W. Mabey)
Date: Wed, 2 May 2007 09:11:07 -0500
Subject: [IPython-dev] [IPython-user] IPython1 Saw alpha1 is released
In-Reply-To: <6ce0ac130704241016i1d50418ao401bee17102d99e5@mail.gmail.com>
References: <6ce0ac130704241016i1d50418ao401bee17102d99e5@mail.gmail.com>
Message-ID: <20070502141107.GF15164@bams.ccf.swri.edu>

Hello,

On Tue, Apr 24, 2007 at 11:16:10AM -0600, Brian Granger wrote:
> In prepration for the IPython sprint this weeked, we are pleased to
> announce the first alpha release of IPython1 "Saw".  This released has
> been 6 months in the making and there are many new things.

I'm using 'saw' for the first time.

It seems that when a remote variable is None, then performing a pull() on
it fails.


In [2]:ipc = kernel.RemoteController(('127.0.0.1',10105))

In [3]:ipc.push
ipc.push     ipc.pushAll  

In [3]:ipc.push( 0, avar=None )
Out[3]:[None]

In [4]:ipc.pull( 'avar' )
---------------------------------------------------------------------------
<class 'ipython1.kernel.error.InvalidEngineID'>Traceback (most recent
call last)

/home/gmabey/src/R9619_dev_acqlibweb/Projects/R9619_NChannelDetection/NED/<ipython console> in <module>()

/usr/local/lib/python2.5/site-packages/ipython1/kernel/multienginexmlrpc.py in pull(self, targets, *keys)
    548         self._checkClientID()
    549         localBlock = self._reallyBlock()
--> 550         result = self._executeRemoteMethod(self._server.pull, self._clientID, localBlock, targets, *keys)
    551         if not localBlock:
    552             result = PendingResult(self, result)

/usr/local/lib/python2.5/site-packages/ipython1/kernel/multienginexmlrpc.py in _executeRemoteMethod(self, f, *args)
    380         try:
    381             rawResult = f(*args)
--> 382             result = self._unpackageResult(rawResult)
    383         except error.InvalidClientID:
    384             self._getClientID()

/usr/local/lib/python2.5/site-packages/ipython1/kernel/multienginexmlrpc.py in _unpackageResult(self, result)
    389     def _unpackageResult(self, result):
    390         result = pickle.loads(result.data)
--> 391         return self._returnOrRaise(result)
    392 
    393     def _returnOrRaise(self, result):

/usr/local/lib/python2.5/site-packages/ipython1/kernel/multienginexmlrpc.py in _returnOrRaise(self, result)
    393     def _returnOrRaise(self, result):
    394         if isinstance(result, failure.Failure):
--> 395             result.raiseException()
    396         else:
    397             return result

/usr/local/stow/twisted-20070319_svn-py2.5/lib/python2.5/site-packages/twisted/python/failure.py in raiseException(self)
    301         information if available.
    302         """
--> 303         raise self.type, self.value, self.tb
    304 
    305 

<class 'ipython1.kernel.error.InvalidEngineID'>: targets argument is not an int, list of ints or 'all'
> /usr/local/stow/twisted-20070319_svn-py2.5/lib/python2.5/site-packages/twisted/python/failure.py(303)raiseException()
    302         """
--> 303         raise self.type, self.value, self.tb
    304 


If not a bug, this is at least a change in behavior from chainsaw, isn't
it?  I couldn't see anything to that effect in the changelog.

Thanks,
Glen


From vivainio at gmail.com  Wed May  2 10:52:23 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 2 May 2007 16:52:23 +0200
Subject: [IPython-dev] Better reporting for non-ascii home dir names
In-Reply-To: <db6b5ecc0705012348k2a42d772t1e6f82f67d717f14@mail.gmail.com>
References: <46cb515a0704300414k3e5057fch20f2c22ab0ba32ed@mail.gmail.com>
	<20070430115911.GH3761@mentat.za.net>
	<46cb515a0704300506i6fad5695g92b0ce24aded63eb@mail.gmail.com>
	<20070430121815.GI3761@mentat.za.net>
	<46cb515a0704300527i352bc04cuf90df73ba4950f4d@mail.gmail.com>
	<db6b5ecc0705012053j13e48f75i6a9d534f1e77a6b5@mail.gmail.com>
	<46cb515a0705012240l3fe6e763n20b9a207775b4c49@mail.gmail.com>
	<db6b5ecc0705012337x5414efddkada8395a19b8d809@mail.gmail.com>
	<db6b5ecc0705012348k2a42d772t1e6f82f67d717f14@mail.gmail.com>
Message-ID: <46cb515a0705020752q58acc63bj2f0225b4aca076@mail.gmail.com>

On 5/2/07, Fernando Perez <fperez.net at gmail.com> wrote:

> On 5/2/07, Fernando Perez <fperez.net at gmail.com> wrote:
>
> > OK.  What about these new tickets, do we leave them for post-0.8.1?
> >
> > http://projects.scipy.org/ipython/ipython/ticket/142

> 142 remains...

Looking at the source, it seems to be a known issue:

          # FIXME: I've been getting many crash reports from python 2.3
            # users, traceable to inspect.py.  If I can find a small test-case
            # to reproduce this, I should either write a better workaround or
            # file a bug report against inspect (if that's the real problem).
            # So far, I haven't been able to find an isolated example to
            # reproduce the problem.

So this is a non-blocker for 0.8.1

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From vivainio at gmail.com  Wed May  2 10:52:23 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 2 May 2007 16:52:23 +0200
Subject: [IPython-dev] Better reporting for non-ascii home dir names
In-Reply-To: <db6b5ecc0705012348k2a42d772t1e6f82f67d717f14@mail.gmail.com>
References: <46cb515a0704300414k3e5057fch20f2c22ab0ba32ed@mail.gmail.com>
	<20070430115911.GH3761@mentat.za.net>
	<46cb515a0704300506i6fad5695g92b0ce24aded63eb@mail.gmail.com>
	<20070430121815.GI3761@mentat.za.net>
	<46cb515a0704300527i352bc04cuf90df73ba4950f4d@mail.gmail.com>
	<db6b5ecc0705012053j13e48f75i6a9d534f1e77a6b5@mail.gmail.com>
	<46cb515a0705012240l3fe6e763n20b9a207775b4c49@mail.gmail.com>
	<db6b5ecc0705012337x5414efddkada8395a19b8d809@mail.gmail.com>
	<db6b5ecc0705012348k2a42d772t1e6f82f67d717f14@mail.gmail.com>
Message-ID: <46cb515a0705020752q58acc63bj2f0225b4aca076@mail.gmail.com>

On 5/2/07, Fernando Perez <fperez.net at gmail.com> wrote:

> On 5/2/07, Fernando Perez <fperez.net at gmail.com> wrote:
>
> > OK.  What about these new tickets, do we leave them for post-0.8.1?
> >
> > http://projects.scipy.org/ipython/ipython/ticket/142

> 142 remains...

Looking at the source, it seems to be a known issue:

          # FIXME: I've been getting many crash reports from python 2.3
            # users, traceable to inspect.py.  If I can find a small test-case
            # to reproduce this, I should either write a better workaround or
            # file a bug report against inspect (if that's the real problem).
            # So far, I haven't been able to find an isolated example to
            # reproduce the problem.

So this is a non-blocker for 0.8.1

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From vivainio at gmail.com  Wed May  2 10:54:02 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 2 May 2007 16:54:02 +0200
Subject: [IPython-dev] Weird KeyboardInterrupts
Message-ID: <46cb515a0705020754y51f3c268k3c80539e3580a7e8@mail.gmail.com>

I've been getting numerous ipython crash reports that indicate
"KeyboardInterrupt" as the problem, yet the users claim to not have
pressed ctrl+c. Anyone have this happening right now?

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From fperez.net at gmail.com  Wed May  2 11:14:01 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 2 May 2007 09:14:01 -0600
Subject: [IPython-dev] IPython in the cheeseshop
In-Reply-To: <46383D30.2090205@livinglogic.de>
References: <46373400.6090208@livinglogic.de>
	<db6b5ecc0705012052v643f7995ne5fdd3fe9d45db@mail.gmail.com>
	<46383D30.2090205@livinglogic.de>
Message-ID: <db6b5ecc0705020814le301a14secb8b2b6058dec44@mail.gmail.com>

On 5/2/07, Walter D?rwald <walter at livinglogic.de> wrote:

> If all else fails, we could always try to convince the cheeseshop
> maintainers to delete the old entry.

Go for it, if you have a spare minute.

Cheers,

f


From fperez.net at gmail.com  Wed May  2 11:16:59 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 2 May 2007 09:16:59 -0600
Subject: [IPython-dev] Weird KeyboardInterrupts
In-Reply-To: <46cb515a0705020754y51f3c268k3c80539e3580a7e8@mail.gmail.com>
References: <46cb515a0705020754y51f3c268k3c80539e3580a7e8@mail.gmail.com>
Message-ID: <db6b5ecc0705020816s37d34401mf5e0d8f1e3283709@mail.gmail.com>

On 5/2/07, Ville M. Vainio <vivainio at gmail.com> wrote:
> I've been getting numerous ipython crash reports that indicate
> "KeyboardInterrupt" as the problem, yet the users claim to not have
> pressed ctrl+c. Anyone have this happening right now?

Can you post one such traceback so we can have a look?

Thanks,


f


From vivainio at gmail.com  Wed May  2 11:29:14 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 2 May 2007 17:29:14 +0200
Subject: [IPython-dev] Weird KeyboardInterrupts
In-Reply-To: <db6b5ecc0705020816s37d34401mf5e0d8f1e3283709@mail.gmail.com>
References: <46cb515a0705020754y51f3c268k3c80539e3580a7e8@mail.gmail.com>
	<db6b5ecc0705020816s37d34401mf5e0d8f1e3283709@mail.gmail.com>
Message-ID: <46cb515a0705020829q784e3cf5oe2139591e54999ce@mail.gmail.com>

On 5/2/07, Fernando Perez <fperez.net at gmail.com> wrote:

> On 5/2/07, Ville M. Vainio <vivainio at gmail.com> wrote:
> > I've been getting numerous ipython crash reports that indicate
> > "KeyboardInterrupt" as the problem, yet the users claim to not have
> > pressed ctrl+c. Anyone have this happening right now?
>
> Can you post one such traceback so we can have a look?

Attached.

It seems to be a part of a "missing readline" exception handling, but
turns to KeyboardInterrupt.

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'
-------------- next part --------------
***************************************************************************

IPython post-mortem report

IPython version: 0.8.0 

SVN revision   : 2191 

Platform info  : os.name -> posix, sys.platform -> darwin

***************************************************************************

Current user configuration structure:

{'Version': 0,
 '__allownew': False,
 'alias': [],
 'args': [],
 'autocall': 1,
 'autoedit_syntax': 0,
 'autoindent': 1,
 'automagic': 1,
 'banner': 1,
 'c': '',
 'cache_size': 1000,
 'classic': 0,
 'color_info': 1,
 'colors': 'NoColor',
 'confirm_exit': 1,
 'debug': 0,
 'deep_reload': 0,
 'editor': 'vi',
 'embedded': False,
 'execfile': [],
 'execute': [''],
 'gthread': 0,
 'help': 0,
 'ignore': 0,
 'import_all': [],
 'import_mod': [],
 'import_some': [[]],
 'include': [],
 'ipythondir': '/Users/veged/.ipython',
 'log': 0,
 'logfile': '',
 'logplay': '',
 'magic_docstrings': 0,
 'messages': 1,
 'multi_line_specials': 1,
 'nosep': 0,
 'object_info_string_level': 0,
 'opts': Struct({'__allownew': True}),
 'pdb': 0,
 'pprint': 1,
 'profile': '',
 'prompt_in1': 'In [\\#]: ',
 'prompt_in2': '   .\\D.: ',
 'prompt_out': 'Out[\\#]: ',
 'prompts_pad_left': 1,
 'pylab': 0,
 'pylab_import_all': 1,
 'q4thread': 0,
 'qthread': 0,
 'quick': 0,
 'quiet': 0,
 'rcfile': 'ipythonrc',
 'readline': 1,
 'readline_merge_completions': 1,
 'readline_omit__names': 0,
 'readline_parse_and_bind': ['tab: complete',
                             '"\\C-l": possible-completions',
                             'set show-all-if-ambiguous on',
                             '"\\C-o": tab-insert',
                             '"\\M-i": "    "',
                             '"\\M-o": "\\d\\d\\d\\d"',
                             '"\\M-I": "\\d\\d\\d\\d"',
                             '"\\C-r": reverse-search-history',
                             '"\\C-s": forward-search-history',
                             '"\\C-p": history-search-backward',
                             '"\\C-n": history-search-forward',
                             '"\\e[A": history-search-backward',
                             '"\\e[B": history-search-forward',
                             '"\\C-k": kill-line',
                             '"\\C-u": unix-line-discard'],
 'readline_remove_delims': '-/~',
 'screen_length': -2,
 'separate_in': '\n',
 'separate_out': '',
 'separate_out2': '',
 'system_header': 'IPython system call: ',
 'system_verbose': 0,
 'term_title': 1,
 'tk': 0,
 'upgrade': 0,
 'wildcards_case_sensitive': 1,
 'wthread': 0,
 'wxversion': '0',
 'xmode': 'Context'}

***************************************************************************

Crash traceback:

---------------------------------------------------------------------------
<type 'exceptions.KeyboardInterrupt'>  Python 2.5: /opt/local/bin/python2.5
                                                   Fri Apr 13 13:44:32 2007
A problem occured executing Python code.  Here is the sequence of function
calls leading up to the error, with the most recent (innermost) call last.

/opt/local/bin/ipython in <module>()
     12 IPython.Shell.IPShell().mainloop(sys_exit=1)
     13 
     14 [or simply IPython.Shell.IPShell().mainloop(1) ]
     15 
     16 and IPython will be your working environment when you start python. The final
     17 sys.exit() call will make python exit transparently when IPython finishes, so
     18 you don't have an extra prompt to get out of.
     19 
     20 This is probably useful to developers who manage multiple Python versions and
     21 don't want to have correspondingly multiple IPython versions. Note that in
     22 this mode, there is no way to pass IPython any command-line options, as those
     23 are trapped first by Python itself.
     24 """
     25 
     26 import IPython
---> 27 IPython.Shell.start().mainloop()
        global IPython.Shell.start.mainloop = undefined
     28 
     29 
     30 
     31 
     32 
     33 
     34 
     35 
     36 
     37 
     38 
     39 
     40 
     41 
     42 

/opt/local/lib/python2.5/site-packages/IPython/Shell.py in mainloop(self=<IPython.Shell.IPShell instance at 0x55aad0>, sys_exit=0, banner=None)
     62 #-----------------------------------------------------------------------------
     63 # This class is trivial now, but I want to have it in to publish a clean
     64 # interface. Later when the internals are reorganized, code that uses this
     65 # shouldn't have to change.
     66 
     67 class IPShell:
     68     """Create an IPython instance."""
     69     
     70     def __init__(self,argv=None,user_ns=None,user_global_ns=None,
     71                  debug=1,shell_class=InteractiveShell):
     72         self.IP = make_IPython(argv,user_ns=user_ns,
     73                                user_global_ns=user_global_ns,
     74                                debug=debug,shell_class=shell_class)
     75 
     76     def mainloop(self,sys_exit=0,banner=None):
---> 77         self.IP.mainloop(banner)
        self.IP.mainloop = <bound method InteractiveShell.mainloop of <IPython.iplib.InteractiveShell object at 0x55b6d0>>
        banner = None
     78         if sys_exit:
     79             sys.exit()
     80 
     81 #-----------------------------------------------------------------------------
     82 class IPShellEmbed:
     83     """Allow embedding an IPython shell into a running program.
     84 
     85     Instances of this class are callable, with the __call__ method being an
     86     alias to the embed() method of an InteractiveShell instance.
     87 
     88     Usage (see also the example-embed.py file for a running example):
     89 
     90     ipshell = IPShellEmbed([argv,banner,exit_msg,rc_override])
     91 
     92     - argv: list containing valid command-line options for IPython, as they

/opt/local/lib/python2.5/site-packages/IPython/iplib.py in mainloop(self=<IPython.iplib.InteractiveShell object at 0x55b6d0>, banner="Python 2.5 (r25:51908, Mar  4 2007, 03:45:52) \nT...ut 'object'. ?object also works, ?? prints more.\n")
   1511 
   1512         If an optional banner argument is given, it will override the
   1513         internally created default banner."""
   1514 
   1515         if self.rc.c:  # Emulate Python's -c option
   1516             self.exec_init_cmd()
   1517         if banner is None:
   1518             if not self.rc.banner:
   1519                 banner = ''
   1520             # banner is string? Use it directly!
   1521             elif isinstance(self.rc.banner,basestring):
   1522                 banner = self.rc.banner
   1523             else:                
   1524                 banner = self.BANNER+self.banner2
   1525 
-> 1526         self.interact(banner)
        self.interact = <bound method InteractiveShell.interact of <IPython.iplib.InteractiveShell object at 0x55b6d0>>
        banner = 'Python 2.5 (r25:51908, Mar  4 2007, 03:45:52) \nType "copyright", "credits" or "license" for more information.\n\nIPython 0.8.0 -- An enhanced Interactive Python.\n?       -> Introduction to IPython\'s features.\n%magic  -> Information about IPython\'s \'magic\' % functions.\nhelp    -> Python\'s own help system.\nobject? -> Details about \'object\'. ?object also works, ?? prints more.\n'
   1527 
   1528     def exec_init_cmd(self):
   1529         """Execute a command given at the command line.
   1530 
   1531         This emulates Python's -c option."""
   1532 
   1533         #sys.argv = ['-c']
   1534         self.push(self.rc.c)
   1535 
   1536     def embed_mainloop(self,header='',local_ns=None,global_ns=None,stack_depth=0):
   1537         """Embeds IPython into a running python program.
   1538 
   1539         Input:
   1540 
   1541           - header: An optional header message can be specified.

/opt/local/lib/python2.5/site-packages/IPython/iplib.py in interact(self=<IPython.iplib.InteractiveShell object at 0x55b6d0>, banner="Python 2.5 (r25:51908, Mar  4 2007, 03:45:52) \nT...ut 'object'. ?object also works, ?? prints more.\n")
   1656                     self.indent_current_nsp = 0
   1657                 more = 0
   1658             except EOFError:
   1659                 if self.autoindent:
   1660                     self.readline_startup_hook(None)
   1661                 self.write('\n')
   1662                 self.exit()
   1663             except bdb.BdbQuit:
   1664                 warn('The Python debugger has exited with a BdbQuit exception.\n'
   1665                      'Because of how pdb handles the stack, it is impossible\n'
   1666                      'for IPython to properly format this particular exception.\n'
   1667                      'IPython will resume normal operation.')
   1668             except:
   1669                 # exceptions here are VERY RARE, but they can be triggered
   1670                 # asynchronously by signal handlers, for example.
-> 1671                 self.showtraceback()
        self.showtraceback = <bound method InteractiveShell.showtraceback of <IPython.iplib.InteractiveShell object at 0x55b6d0>>
   1672             else:
   1673                 more = self.push(line)
   1674                 if (self.SyntaxTB.last_syntax_error and
   1675                     self.rc.autoedit_syntax):
   1676                     self.edit_syntax_error()
   1677             
   1678         # We are off again...
   1679         __builtin__.__dict__['__IPYTHON__active'] -= 1
   1680 
   1681     def excepthook(self, etype, value, tb):
   1682       """One more defense for GUI apps that call sys.excepthook.
   1683 
   1684       GUI frameworks like wxPython trap exceptions and call
   1685       sys.excepthook themselves.  I guess this is a feature that
   1686       enables them to keep running after exceptions that would

/opt/local/lib/python2.5/site-packages/IPython/iplib.py in showtraceback(self=<IPython.iplib.InteractiveShell object at 0x55b6d0>, exc_tuple=None, filename=None, tb_offset=None)
   1489 
   1490         if etype is SyntaxError:
   1491             self.showsyntaxerror(filename)
   1492         else:
   1493             # WARNING: these variables are somewhat deprecated and not
   1494             # necessarily safe to use in a threaded environment, but tools
   1495             # like pdb depend on their existence, so let's set them.  If we
   1496             # find problems in the field, we'll need to revisit their use.
   1497             sys.last_type = etype
   1498             sys.last_value = value
   1499             sys.last_traceback = tb
   1500 
   1501             if etype in self.custom_exceptions:
   1502                 self.CustomTB(etype,value,tb)
   1503             else:
-> 1504                 self.InteractiveTB(etype,value,tb,tb_offset=tb_offset)
        self.InteractiveTB = <IPython.ultraTB.AutoFormattedTB instance at 0x11923f0>
        etype = <type 'exceptions.AttributeError'>
        value = AttributeError("'NoneType' object has no attribute 'set_completer'",)
        tb = <traceback object at 0x11bc850>
        tb_offset = None
   1505                 if self.InteractiveTB.call_pdb and self.has_readline:
   1506                     # pdb mucks up readline, fix it back
   1507                     self.set_completer()
   1508 
   1509     def mainloop(self,banner=None):
   1510         """Creates the local namespace and starts the mainloop.
   1511 
   1512         If an optional banner argument is given, it will override the
   1513         internally created default banner."""
   1514 
   1515         if self.rc.c:  # Emulate Python's -c option
   1516             self.exec_init_cmd()
   1517         if banner is None:
   1518             if not self.rc.banner:
   1519                 banner = ''

/opt/local/lib/python2.5/site-packages/IPython/ultraTB.py in __call__(self=<IPython.ultraTB.AutoFormattedTB instance at 0x11923f0>, etype=<type 'exceptions.AttributeError'>, evalue=AttributeError("'NoneType' object has no attribute 'set_completer'",), etb=<traceback object at 0x11bc850>, out=<IPython.genutils.IOStream instance at 0x5ce1c0>, tb_offset=None)
    856           - out: an open file-like object to direct output to.
    857 
    858           - tb_offset: the number of frames to skip over in the stack, on a
    859           per-call basis (this overrides temporarily the instance's tb_offset
    860           given at initialization time.  """
    861         
    862         if out is None:
    863             out = Term.cerr
    864         Term.cout.flush()
    865         out.flush()
    866         if tb_offset is not None:
    867             tb_offset, self.tb_offset = self.tb_offset, tb_offset
    868             print >> out, self.text(etype, evalue, etb)
    869             self.tb_offset = tb_offset
    870         else:
--> 871             print >> out, self.text(etype, evalue, etb)
        out = <IPython.genutils.IOStream instance at 0x5ce1c0>
        self.text = <bound method AutoFormattedTB.text of <IPython.ultraTB.AutoFormattedTB instance at 0x11923f0>>
        etype = <type 'exceptions.AttributeError'>
        evalue = AttributeError("'NoneType' object has no attribute 'set_completer'",)
        etb = <traceback object at 0x11bc850>
    872         self.debugger()
    873 
    874     def text(self,etype=None,value=None,tb=None,context=5,mode=None):
    875         if etype is None:
    876             etype,value,tb = sys.exc_info()
    877         self.tb = tb
    878         return FormattedTB.text(self,etype,value,tb,context=5,mode=mode)
    879 
    880 #---------------------------------------------------------------------------
    881 # A simple class to preserve Nathan's original functionality.
    882 class ColorTB(FormattedTB):
    883     """Shorthand to initialize a FormattedTB in Linux colors mode."""
    884     def __init__(self,color_scheme='Linux',call_pdb=0):
    885         FormattedTB.__init__(self,color_scheme=color_scheme,
    886                              call_pdb=call_pdb)

/opt/local/lib/python2.5/site-packages/IPython/ultraTB.py in text(self=<IPython.ultraTB.AutoFormattedTB instance at 0x11923f0>, etype=<type 'exceptions.AttributeError'>, value=AttributeError("'NoneType' object has no attribute 'set_completer'",), tb=<traceback object at 0x11bc850>, context=5, mode=None)
    863             out = Term.cerr
    864         Term.cout.flush()
    865         out.flush()
    866         if tb_offset is not None:
    867             tb_offset, self.tb_offset = self.tb_offset, tb_offset
    868             print >> out, self.text(etype, evalue, etb)
    869             self.tb_offset = tb_offset
    870         else:
    871             print >> out, self.text(etype, evalue, etb)
    872         self.debugger()
    873 
    874     def text(self,etype=None,value=None,tb=None,context=5,mode=None):
    875         if etype is None:
    876             etype,value,tb = sys.exc_info()
    877         self.tb = tb
--> 878         return FormattedTB.text(self,etype,value,tb,context=5,mode=mode)
        global FormattedTB.text = <unbound method FormattedTB.text>
        self = <IPython.ultraTB.AutoFormattedTB instance at 0x11923f0>
        etype = <type 'exceptions.AttributeError'>
        value = AttributeError("'NoneType' object has no attribute 'set_completer'",)
        tb = <traceback object at 0x11bc850>
        context = 5
        mode = None
    879 
    880 #---------------------------------------------------------------------------
    881 # A simple class to preserve Nathan's original functionality.
    882 class ColorTB(FormattedTB):
    883     """Shorthand to initialize a FormattedTB in Linux colors mode."""
    884     def __init__(self,color_scheme='Linux',call_pdb=0):
    885         FormattedTB.__init__(self,color_scheme=color_scheme,
    886                              call_pdb=call_pdb)
    887 
    888 #----------------------------------------------------------------------------
    889 # module testing (minimal)
    890 if __name__ == "__main__":
    891     def spam(c, (d, e)):
    892         x = c + d
    893         y = c * d

/opt/local/lib/python2.5/site-packages/IPython/ultraTB.py in text(self=<IPython.ultraTB.AutoFormattedTB instance at 0x11923f0>, etype=<type 'exceptions.AttributeError'>, value=AttributeError("'NoneType' object has no attribute 'set_completer'",), tb=<traceback object at 0x11bc850>, context=5, mode='Context')
    784         if tb:
    785             return traceback.extract_tb(tb)
    786         else:
    787             return None
    788 
    789     def text(self, etype, value, tb,context=5,mode=None):
    790         """Return formatted traceback.
    791 
    792         If the optional mode parameter is given, it overrides the current
    793         mode."""
    794 
    795         if mode is None:
    796             mode = self.mode
    797         if mode in self.verbose_modes:
    798             # verbose modes need a full traceback
--> 799             return VerboseTB.text(self,etype, value, tb,context=5)
        global VerboseTB.text = <unbound method VerboseTB.text>
        self = <IPython.ultraTB.AutoFormattedTB instance at 0x11923f0>
        etype = <type 'exceptions.AttributeError'>
        value = AttributeError("'NoneType' object has no attribute 'set_completer'",)
        tb = <traceback object at 0x11bc850>
        context = 5
    800         else:
    801             # We must check the source cache because otherwise we can print
    802             # out-of-date source code.
    803             linecache.checkcache()
    804             # Now we can extract and format the exception
    805             elist = self._extract_tb(tb)
    806             if len(elist) > self.tb_offset:
    807                 del elist[:self.tb_offset]
    808             return ListTB.text(self,etype,value,elist)
    809 
    810     def set_mode(self,mode=None):
    811         """Switch to the desired mode.
    812 
    813         If mode is not specified, cycles through the available modes."""
    814 

/opt/local/lib/python2.5/site-packages/IPython/ultraTB.py in text(self=<IPython.ultraTB.AutoFormattedTB instance at 0x11923f0>, etype=<type 'exceptions.AttributeError'>, evalue=AttributeError("'NoneType' object has no attribute 'set_completer'",), etb=<traceback object at 0x11bc850>, context=5)
    600                     raise IndexError
    601             # we need to store a bit of state in the tokenizer to build
    602             # dotted names
    603             tokeneater.name_cont = False
    604 
    605             def linereader(file=file, lnum=[lnum], getline=linecache.getline):
    606                 line = getline(file, lnum[0])
    607                 lnum[0] += 1
    608                 return line
    609 
    610             # Build the list of names on this line of code where the exception
    611             # occurred.
    612             try:
    613                 # This builds the names list in-place by capturing it from the
    614                 # enclosing scope.
--> 615                 tokenize.tokenize(linereader, tokeneater)
        global tokenize.tokenize = <function tokenize at 0x5c20f0>
        linereader = <function linereader at 0x1225570>
        global tokeneater = undefined
    616             except IndexError:
    617                 # signals exit of tokenizer
    618                 pass
    619             except tokenize.TokenError,msg:
    620                 _m = ("An unexpected error occurred while tokenizing input\n"
    621                       "The following traceback may be corrupted or invalid\n"
    622                       "The error message is: %s\n" % msg)
    623                 error(_m)
    624             
    625             # prune names list of duplicates, but keep the right order
    626             unique_names = uniq_stable(names)
    627 
    628             # Start loop over vars
    629             lvals = []
    630             if self.include_vars:

/opt/local/lib/python2.5/tokenize.py in tokenize(readline=<function linereader at 0x1225570>, tokeneater=<function tokeneater at 0x1225c70>)
    138 
    139 def tokenize(readline, tokeneater=printtoken):
    140     """
    141     The tokenize() function accepts two parameters: one representing the
    142     input stream, and one providing an output mechanism for tokenize().
    143 
    144     The first parameter, readline, must be a callable object which provides
    145     the same interface as the readline() method of built-in file objects.
    146     Each call to the function should return one line of input as a string.
    147 
    148     The second parameter, tokeneater, must also be a callable object. It is
    149     called once for each token, with five arguments, corresponding to the
    150     tuples generated by generate_tokens().
    151     """
    152     try:
--> 153         tokenize_loop(readline, tokeneater)
        global tokenize_loop = <function tokenize_loop at 0x5c2130>
        readline = <function linereader at 0x1225570>
        tokeneater = <function tokeneater at 0x1225c70>
    154     except StopTokenizing:
    155         pass
    156 
    157 # backwards compatible interface
    158 def tokenize_loop(readline, tokeneater):
    159     for token_info in generate_tokens(readline):
    160         tokeneater(*token_info)
    161 
    162 
    163 def untokenize(iterable):
    164     """Transform tokens back into Python source code.
    165 
    166     Each element returned by the iterable must be a token sequence
    167     with at least two elements, a token number and token value.
    168 

/opt/local/lib/python2.5/tokenize.py in tokenize_loop(readline=<function linereader at 0x1225570>, tokeneater=<function tokeneater at 0x1225c70>)
    144     The first parameter, readline, must be a callable object which provides
    145     the same interface as the readline() method of built-in file objects.
    146     Each call to the function should return one line of input as a string.
    147 
    148     The second parameter, tokeneater, must also be a callable object. It is
    149     called once for each token, with five arguments, corresponding to the
    150     tuples generated by generate_tokens().
    151     """
    152     try:
    153         tokenize_loop(readline, tokeneater)
    154     except StopTokenizing:
    155         pass
    156 
    157 # backwards compatible interface
    158 def tokenize_loop(readline, tokeneater):
--> 159     for token_info in generate_tokens(readline):
        token_info = (5, '        ', (1, 0), (1, 8), '        self.readline.set_completer(self.Completer.complete)\n')
        global generate_tokens = <function generate_tokens at 0x5c21b0>
        readline = <function linereader at 0x1225570>
    160         tokeneater(*token_info)
    161 
    162 
    163 def untokenize(iterable):
    164     """Transform tokens back into Python source code.
    165 
    166     Each element returned by the iterable must be a token sequence
    167     with at least two elements, a token number and token value.
    168 
    169     Round-trip invariant:
    170         # Output text will tokenize the back to the input
    171         t1 = [tok[:2] for tok in generate_tokens(f.readline)]
    172         newcode = untokenize(t1)
    173         readline = iter(newcode.splitlines(1)).next
    174         t2 = [tok[:2] for tokin generate_tokens(readline)]

/opt/local/lib/python2.5/tokenize.py in generate_tokens(readline=<function linereader at 0x1225570>)
    272                 yield (INDENT, line[:pos], (lnum, 0), (lnum, pos), line)
    273             while column < indents[-1]:
    274                 if column not in indents:
    275                     raise IndentationError(
    276                         "unindent does not match any outer indentation level",
    277                         ("<tokenize>", lnum, pos, line))
    278                 indents = indents[:-1]
    279                 yield (DEDENT, '', (lnum, pos), (lnum, pos), line)
    280 
    281         else:                                  # continued statement
    282             if not line:
    283                 raise TokenError, ("EOF in multi-line statement", (lnum, 0))
    284             continued = 0
    285 
    286         while pos < max:
--> 287             pseudomatch = pseudoprog.match(line, pos)
        pseudomatch = undefined
        global pseudoprog.match = <built-in method match of _sre.SRE_Pattern object at 0x1864e00>
        line = '        self.readline.set_completer(self.Completer.complete)\n'
        pos = 8
    288             if pseudomatch:                                # scan for tokens
    289                 start, end = pseudomatch.span(1)
    290                 spos, epos, pos = (lnum, start), (lnum, end), end
    291                 token, initial = line[start:end], line[start]
    292 
    293                 if initial in numchars or \
    294                    (initial == '.' and token != '.'):      # ordinary number
    295                     yield (NUMBER, token, spos, epos, line)
    296                 elif initial in '\r\n':
    297                     yield (parenlev > 0 and NL or NEWLINE,
    298                                token, spos, epos, line)
    299                 elif initial == '#':
    300                     yield (COMMENT, token, spos, epos, line)
    301                 elif token in triple_quoted:
    302                     endprog = endprogs[token]

<type 'exceptions.KeyboardInterrupt'>: 

***************************************************************************

History of session input:

*** Last line of input (may not be in above history):

From fperez.net at gmail.com  Wed May  2 13:29:15 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 2 May 2007 11:29:15 -0600
Subject: [IPython-dev] Weird KeyboardInterrupts
In-Reply-To: <46cb515a0705020829q784e3cf5oe2139591e54999ce@mail.gmail.com>
References: <46cb515a0705020754y51f3c268k3c80539e3580a7e8@mail.gmail.com>
	<db6b5ecc0705020816s37d34401mf5e0d8f1e3283709@mail.gmail.com>
	<46cb515a0705020829q784e3cf5oe2139591e54999ce@mail.gmail.com>
Message-ID: <db6b5ecc0705021029w4a6686d0j70ac8a0e15e27386@mail.gmail.com>

On 5/2/07, Ville M. Vainio <vivainio at gmail.com> wrote:
> On 5/2/07, Fernando Perez <fperez.net at gmail.com> wrote:
>
> > On 5/2/07, Ville M. Vainio <vivainio at gmail.com> wrote:
> > > I've been getting numerous ipython crash reports that indicate
> > > "KeyboardInterrupt" as the problem, yet the users claim to not have
> > > pressed ctrl+c. Anyone have this happening right now?
> >
> > Can you post one such traceback so we can have a look?
>
> Attached.
>
> It seems to be a part of a "missing readline" exception handling, but
> turns to KeyboardInterrupt.

That's weird... Are all of these reports under Darwin (OSX)?

It's worth noting that the 'readline' mentioned in there is NOT the
keyboard-handling readline library, but rather an argument to the
input tokenization routines.  See the source to tokenize.py in the
stdlib for details; unfortunately they use the name 'readline' in many
places as an argument, which is very confusing.

These crashes are even stranger because they do NOT report using any
of the threaded exception handling at all, so that's not the root
cause of the problem.

All I can think of is that this is happening to someone who mis-built
his or her python.  The tb indicates the user has a hand-built python:

/opt/local/lib/python2.5/tokenize.py

and under OSX GNU readline is NOT available by default.  So it's quite
possible that they have a mis-built Python and we're failing
ungracefully in such circumstances.

Since we provide our own readline under Win32, and Linux pretty much
always has it around, this leaves OSX as a potentially problematic
platform, especially because Apple ships something that *seems* to be
readline but isn't (for BSD/GPL reasons).

In summary, it's possible that this is a problem on the user's end, to
which we are not responding as robustly as we should.  But I'm not
really 100% sure, unfortunately.

What is certain is that it's NOT related to the threading/Ctrl-C
tricks I added recently, since none of the threaded classes are active
in this traceback.

Cheers,


f


From vivainio at gmail.com  Wed May  2 13:32:11 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 2 May 2007 19:32:11 +0200
Subject: [IPython-dev] Weird KeyboardInterrupts
In-Reply-To: <db6b5ecc0705021029w4a6686d0j70ac8a0e15e27386@mail.gmail.com>
References: <46cb515a0705020754y51f3c268k3c80539e3580a7e8@mail.gmail.com>
	<db6b5ecc0705020816s37d34401mf5e0d8f1e3283709@mail.gmail.com>
	<46cb515a0705020829q784e3cf5oe2139591e54999ce@mail.gmail.com>
	<db6b5ecc0705021029w4a6686d0j70ac8a0e15e27386@mail.gmail.com>
Message-ID: <46cb515a0705021032n1c7ec1cah3682c5be703a2062@mail.gmail.com>

On 5/2/07, Fernando Perez <fperez.net at gmail.com> wrote:

> What is certain is that it's NOT related to the threading/Ctrl-C
> tricks I added recently, since none of the threaded classes are active
> in this traceback.

That's great, it was my main worry.

Should we aim for the weekend release of 0.8.1?

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From fperez.net at gmail.com  Wed May  2 13:35:28 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 2 May 2007 11:35:28 -0600
Subject: [IPython-dev] Weird KeyboardInterrupts
In-Reply-To: <46cb515a0705021032n1c7ec1cah3682c5be703a2062@mail.gmail.com>
References: <46cb515a0705020754y51f3c268k3c80539e3580a7e8@mail.gmail.com>
	<db6b5ecc0705020816s37d34401mf5e0d8f1e3283709@mail.gmail.com>
	<46cb515a0705020829q784e3cf5oe2139591e54999ce@mail.gmail.com>
	<db6b5ecc0705021029w4a6686d0j70ac8a0e15e27386@mail.gmail.com>
	<46cb515a0705021032n1c7ec1cah3682c5be703a2062@mail.gmail.com>
Message-ID: <db6b5ecc0705021035x2479c361if5e96dd489a31c9a@mail.gmail.com>

On 5/2/07, Ville M. Vainio <vivainio at gmail.com> wrote:
> On 5/2/07, Fernando Perez <fperez.net at gmail.com> wrote:
>
> > What is certain is that it's NOT related to the threading/Ctrl-C
> > tricks I added recently, since none of the threaded classes are active
> > in this traceback.
>
> That's great, it was my main worry.

Yup, me too.

> Should we aim for the weekend release of 0.8.1?

Let's do Monday/Tuesday: I have some travel away from internet
connections this weekend.  I'll catch up on Monday on commits, and
barring any emergency messages to the contrary, will push the release
Monday or Tuesday.  OK?

Cheers,

f


From fperez.net at gmail.com  Wed May  2 14:18:23 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 2 May 2007 12:18:23 -0600
Subject: [IPython-dev] Better reporting for non-ascii home dir names
In-Reply-To: <46cb515a0705020752q58acc63bj2f0225b4aca076@mail.gmail.com>
References: <46cb515a0704300414k3e5057fch20f2c22ab0ba32ed@mail.gmail.com>
	<20070430115911.GH3761@mentat.za.net>
	<46cb515a0704300506i6fad5695g92b0ce24aded63eb@mail.gmail.com>
	<20070430121815.GI3761@mentat.za.net>
	<46cb515a0704300527i352bc04cuf90df73ba4950f4d@mail.gmail.com>
	<db6b5ecc0705012053j13e48f75i6a9d534f1e77a6b5@mail.gmail.com>
	<46cb515a0705012240l3fe6e763n20b9a207775b4c49@mail.gmail.com>
	<db6b5ecc0705012337x5414efddkada8395a19b8d809@mail.gmail.com>
	<db6b5ecc0705012348k2a42d772t1e6f82f67d717f14@mail.gmail.com>
	<46cb515a0705020752q58acc63bj2f0225b4aca076@mail.gmail.com>
Message-ID: <db6b5ecc0705021118y17986f5cw52370fe9c904b6ee@mail.gmail.com>

On 5/2/07, Ville M. Vainio <vivainio at gmail.com> wrote:

> Looking at the source, it seems to be a known issue:
>
>           # FIXME: I've been getting many crash reports from python 2.3
>             # users, traceable to inspect.py.  If I can find a small test-case
>             # to reproduce this, I should either write a better workaround or
>             # file a bug report against inspect (if that's the real problem).
>             # So far, I haven't been able to find an isolated example to
>             # reproduce the problem.
>
> So this is a non-blocker for 0.8.1

Yup, I've known about it for a long time, and would love to fix it if
only we had a small, easily reproducible test case.  I've added a
comment asking for such on the ticket page.

cheers,

f


From fperez.net at gmail.com  Wed May  2 14:18:23 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 2 May 2007 12:18:23 -0600
Subject: [IPython-dev] Better reporting for non-ascii home dir names
In-Reply-To: <46cb515a0705020752q58acc63bj2f0225b4aca076@mail.gmail.com>
References: <46cb515a0704300414k3e5057fch20f2c22ab0ba32ed@mail.gmail.com>
	<20070430115911.GH3761@mentat.za.net>
	<46cb515a0704300506i6fad5695g92b0ce24aded63eb@mail.gmail.com>
	<20070430121815.GI3761@mentat.za.net>
	<46cb515a0704300527i352bc04cuf90df73ba4950f4d@mail.gmail.com>
	<db6b5ecc0705012053j13e48f75i6a9d534f1e77a6b5@mail.gmail.com>
	<46cb515a0705012240l3fe6e763n20b9a207775b4c49@mail.gmail.com>
	<db6b5ecc0705012337x5414efddkada8395a19b8d809@mail.gmail.com>
	<db6b5ecc0705012348k2a42d772t1e6f82f67d717f14@mail.gmail.com>
	<46cb515a0705020752q58acc63bj2f0225b4aca076@mail.gmail.com>
Message-ID: <db6b5ecc0705021118y17986f5cw52370fe9c904b6ee@mail.gmail.com>

On 5/2/07, Ville M. Vainio <vivainio at gmail.com> wrote:

> Looking at the source, it seems to be a known issue:
>
>           # FIXME: I've been getting many crash reports from python 2.3
>             # users, traceable to inspect.py.  If I can find a small test-case
>             # to reproduce this, I should either write a better workaround or
>             # file a bug report against inspect (if that's the real problem).
>             # So far, I haven't been able to find an isolated example to
>             # reproduce the problem.
>
> So this is a non-blocker for 0.8.1

Yup, I've known about it for a long time, and would love to fix it if
only we had a small, easily reproducible test case.  I've added a
comment asking for such on the ticket page.

cheers,

f


From list-ener at strank.info  Thu May  3 14:08:16 2007
From: list-ener at strank.info (Stefan Rank)
Date: Thu, 03 May 2007 20:08:16 +0200
Subject: [IPython-dev] callback API for readline (was Re: ipython embedded
 in twisted, no threads)
In-Reply-To: <4638806E.4090300@strank.info>
References: <4623183F.4070807@strank.info>	<4623BD67.4010007@bostream.nu>	<4623F754.9060706@strank.info>	<46266553.2020602@bostream.nu>
	<4638806E.4090300@strank.info>
Message-ID: <463A2510.207@strank.info>

on 02.05.2007 14:13 Stefan Rank said the following:
> on 18.04.2007 20:37 J?rgen Stenarson said the following:

<snip: async emacs.py additions>

> I will also try to expose the GNU readline callback variant on Linux 
> using ctypes and see how it behaves.

Attached is an updated version of the test script that works on both
Windows (requires the patched emacs.py) and Linux.

However: there are additional newlines printed on Windows (see below).
Does pyreadline print a newline before prompting?
Or is there some interaction with normal print statements?

cheers,
stefan


Output on Linux::

   wrstl at TOPFLAP-pm735 $ python readlinecallbacktest.py
   Starting test, please do type:
   jjjfss
   Got line: jjjfss
   Got 1 of 10, more typing please:
   alsddf
   Got line: alsddf
   Got 2 of 10, more typing please:
   asdf
   Got line: asdf
   Got 3 of 10, more typing please:
   ...
   Got 9 of 10, more typing please:
   adsf
   Got line: adsf
   Got 10 of 10, more typing please:
   asdf
   Got line: asdf
   Done, index = 9
   wrstl at TOPFLAP-pm735 $


Output on Windows::

   D:\HOME\temp>python readlinecallbacktest.py
   Starting test, please do type:
   asdf
   Got line: asdf

   Got 1 of 10, more typing please:
   fff
   Got line: fff

   Got 2 of 10, more typing please:
   assd
   Got line: assd

   Got 3 of 10, more typing please:
   ...
   Got 9 of 10, more typing please:
   adf
   Got line: adf

   Got 10 of 10, more typing please:
   adf
   Got line: adf

   Done, index = 11

   D:\HOME\temp>



From list-ener at strank.info  Thu May  3 14:11:19 2007
From: list-ener at strank.info (Stefan Rank)
Date: Thu, 03 May 2007 20:11:19 +0200
Subject: [IPython-dev] callback API for readline [missing attachment] (was
 Re: ipython embedded in twisted, no threads)
In-Reply-To: <4638806E.4090300@strank.info>
References: <4623183F.4070807@strank.info>	<4623BD67.4010007@bostream.nu>	<4623F754.9060706@strank.info>	<46266553.2020602@bostream.nu>
	<4638806E.4090300@strank.info>
Message-ID: <463A25C7.6010307@strank.info>

[[Sending again, this time including the attachment =) ]]

on 02.05.2007 14:13 Stefan Rank said the following:
> on 18.04.2007 20:37 J?rgen Stenarson said the following:

<snip: async emacs.py additions>

> I will also try to expose the GNU readline callback variant on Linux 
> using ctypes and see how it behaves.

Attached is an updated version of the test script that works on both
Windows (requires the patched emacs.py) and Linux.

However: there are additional newlines printed on Windows (see below).
Does pyreadline print a newline before prompting?
Or is there some interaction with normal print statements?

cheers,
stefan


Output on Linux::

   wrstl at TOPFLAP-pm735 $ python readlinecallbacktest.py
   Starting test, please do type:
   jjjfss
   Got line: jjjfss
   Got 1 of 10, more typing please:
   alsddf
   Got line: alsddf
   Got 2 of 10, more typing please:
   asdf
   Got line: asdf
   Got 3 of 10, more typing please:
   ...
   Got 9 of 10, more typing please:
   adsf
   Got line: adsf
   Got 10 of 10, more typing please:
   asdf
   Got line: asdf
   Done, index = 9
   wrstl at TOPFLAP-pm735 $


Output on Windows::

   D:\HOME\temp>python readlinecallbacktest.py
   Starting test, please do type:
   asdf
   Got line: asdf

   Got 1 of 10, more typing please:
   fff
   Got line: fff

   Got 2 of 10, more typing please:
   assd
   Got line: assd

   Got 3 of 10, more typing please:
   ...
   Got 9 of 10, more typing please:
   adf
   Got line: adf

   Got 10 of 10, more typing please:
   adf
   Got line: adf

   Done, index = 11

   D:\HOME\temp>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: readlinecallbacktest.py
Type: text/x-python
Size: 4549 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20070503/b6e9dfaa/attachment.py>

From vivainio at gmail.com  Thu May  3 14:36:12 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Thu, 3 May 2007 20:36:12 +0200
Subject: [IPython-dev] prefilter reorg status
Message-ID: <46cb515a0705031136hcc1d626w8aabbb16d8291ee3@mail.gmail.com>

Hi Dan,

Care to post a status update of your prefilter cleanups? What actually
got in, what's their shape now etc.?

I'd liko to dump any kind of cleanups you might still have into svn
just after 0.8.1, since I have some cleanups in that area in mind as
well.

And sorry if the answer to this question should be obvious, it
happened on time when I had very little time for ipython.

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From fperez.net at gmail.com  Thu May  3 15:51:23 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 3 May 2007 13:51:23 -0600
Subject: [IPython-dev] prefilter reorg status
In-Reply-To: <46cb515a0705031136hcc1d626w8aabbb16d8291ee3@mail.gmail.com>
References: <46cb515a0705031136hcc1d626w8aabbb16d8291ee3@mail.gmail.com>
Message-ID: <db6b5ecc0705031251h7215ffecja8aea94798dfb695@mail.gmail.com>

On 5/3/07, Ville M. Vainio <vivainio at gmail.com> wrote:
> Hi Dan,
>
> Care to post a status update of your prefilter cleanups? What actually
> got in, what's their shape now etc.?
>
> I'd liko to dump any kind of cleanups you might still have into svn
> just after 0.8.1, since I have some cleanups in that area in mind as
> well.
>
> And sorry if the answer to this question should be obvious, it
> happened on time when I had very little time for ipython.

At this point, it's probably worth starting to put this code into the
new work branch.  Here we've put the results of this weekend's sprint:

http://projects.scipy.org/ipython/ipython/browser/ipython/branches/sprint1/ipython1/core1

in particular, the above links to where the 'core' will go,
effectively all the components that will make up what today's IPython
is, but isolated into stnadalone entities that can be developed,
tested and reused with more flexibility.

The input filtering will go into the translator module, so I'd suggest
Dan start hacking there.

My intent is to keep the window of trunk+separate core as short as
possible, so that sooner rather than later we can move everyone over
and development effort isn't spread over two codebases.

Obviously we'll still have users on trunk for a while, but if we can
get this codebase to mature quickly, that period won't be too long.

Cheers,

f


From gakusei at dakotacom.net  Thu May  3 16:22:43 2007
From: gakusei at dakotacom.net (Paul Mueller)
Date: Thu, 3 May 2007 13:22:43 -0700
Subject: [IPython-dev] Unicode bug in %whos, with patch
Message-ID: <20070503202243.GA7261@localhost.localdomain>

Hi,

If you have a unicode variable with a character whose ordinal is >= 128, you
get a UnicodeEncodeError on using %whos (this is using r2304):

In [1]:u = u'\x80'

In [2]:%whos
Variable   Type       Data/Info
-------------------------------
u          unicode   ---------------------------------------------------------------------------
<type 'exceptions.UnicodeEncodeError'>    Traceback (most recent call last)

/home/yuurei/src/mods/ipython/<ipython console> in <module>()

/home/yuurei/src/mods/ipython/IPython/iplib.py in ipmagic(self, arg_s)
    962         else:
    963             magic_args = self.var_expand(magic_args,1)
--> 964             return fn(magic_args)
    965
    966     def ipalias(self,arg_s):

/home/yuurei/src/mods/ipython/IPython/Magic.py in magic_whos(self, parameter_s)
   1057                         print '(%s Mb)' % (vbytes/Mb,)
   1058             else:
-> 1059                 vstr = str(var).replace('\n','\\n')
   1060                 if len(vstr) < 50:
   1061                     print vstr

<type 'exceptions.UnicodeEncodeError'>: 'ascii' codec can't encode character u'\x80' in position 0: ordinal not in range(128)


I've attached a patch that fixes this.

Paul Mueller
-------------- next part --------------
Index: IPython/Magic.py
===================================================================
--- IPython/Magic.py	(revision 2304)
+++ IPython/Magic.py	(working copy)
@@ -1056,7 +1056,12 @@
                     else:
                         print '(%s Mb)' % (vbytes/Mb,)
             else:
-                vstr = str(var).replace('\n','\\n')
+                try:
+                    vstr = str(var)
+                except UnicodeEncodeError:
+                    vstr = unicode(var).encode(sys.getdefaultencoding(),
+                                               'backslashreplace')
+                vstr = vstr.replace('\n','\\n')
                 if len(vstr) < 50:
                     print vstr
                 else:

From vivainio at gmail.com  Thu May  3 16:23:52 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Thu, 3 May 2007 22:23:52 +0200
Subject: [IPython-dev] Macro redesign
Message-ID: <46cb515a0705031323m50db124frcfe5adfe9988b062@mail.gmail.com>

Some post-0.8.2 brainstorming:

I am not sure I like the current approach to macros. They have a
"special" role Prompts.cachedoutput (if output is a macro, it gets
called):

           if isinstance(arg,Macro):
                print 'Executing Macro...'
                # in case the macro takes a long time to execute
                Term.cout.flush()
                self.shell.runlines(arg.value)
                return None


I think Macro class should have __call__(m_arg), and get called
normally via 'autocall' mechanism.

Or we could add some extra code that always calls macros, even when
autocall is off. IpyAutocallMixin subclass, perhaps?

The rationale? Apart from abstract ideas like avoiding "special
casing", I'd like to pass arguments to macros, and return values from
them. This makes sense when you think how you'd normally write a small
"script" - run some commands, then %edit the macro.

You would access m_arg through itpl syntax ($m_arg), and return values
through assigning to special variable called m_ret.

This would allow using macros for many things you need to write
functions, magics or aliases now.

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From robert.kern at gmail.com  Thu May  3 17:52:32 2007
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 03 May 2007 16:52:32 -0500
Subject: [IPython-dev] Macro redesign
In-Reply-To: <46cb515a0705031323m50db124frcfe5adfe9988b062@mail.gmail.com>
References: <46cb515a0705031323m50db124frcfe5adfe9988b062@mail.gmail.com>
Message-ID: <f1dlj1$hjs$1@sea.gmane.org>

Ville M. Vainio wrote:
> Some post-0.8.2 brainstorming:
> 
> I am not sure I like the current approach to macros. They have a
> "special" role Prompts.cachedoutput (if output is a macro, it gets
> called):
> 
>            if isinstance(arg,Macro):
>                 print 'Executing Macro...'
>                 # in case the macro takes a long time to execute
>                 Term.cout.flush()
>                 self.shell.runlines(arg.value)
>                 return None
> 
> 
> I think Macro class should have __call__(m_arg), and get called
> normally via 'autocall' mechanism.
> 
> Or we could add some extra code that always calls macros, even when
> autocall is off. IpyAutocallMixin subclass, perhaps?
> 
> The rationale? Apart from abstract ideas like avoiding "special
> casing", I'd like to pass arguments to macros, and return values from
> them. This makes sense when you think how you'd normally write a small
> "script" - run some commands, then %edit the macro.
> 
> You would access m_arg through itpl syntax ($m_arg), and return values
> through assigning to special variable called m_ret.
> 
> This would allow using macros for many things you need to write
> functions, magics or aliases now.

That would pretty drastically change the semantics of macros. Macros are
currently simply executed in the interpreter's namespace. If you ultimately turn
them into functions, then the only interaction between the macro and the
namespace would be m_arg and m_ret.

The normal way you make macros would be gone, too. Macros are made from commands
that you've already executed, but $m_arg doesn't exist until you've made it into
a macro. You might be able to implement your way around it, but you would be
replacing one small special case (which isn't so special in the core1
refactoring) into a bunch of special cases.

Fernando and I had considered implementing macros by expanding them in the
"translation" phase (a la autocall), but we rejected it for some reason.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco



From vivainio at gmail.com  Fri May  4 01:47:15 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Fri, 4 May 2007 07:47:15 +0200
Subject: [IPython-dev] Macro redesign
In-Reply-To: <f1dlj1$hjs$1@sea.gmane.org>
References: <46cb515a0705031323m50db124frcfe5adfe9988b062@mail.gmail.com>
	<f1dlj1$hjs$1@sea.gmane.org>
Message-ID: <46cb515a0705032247r51015foa1a1b411740acae3@mail.gmail.com>

On 5/3/07, Robert Kern <robert.kern at gmail.com> wrote:

> > This would allow using macros for many things you need to write
> > functions, magics or aliases now.
>
> That would pretty drastically change the semantics of macros. Macros are
> currently simply executed in the interpreter's namespace. If you ultimately turn

Yeah, and macro's would still be strings that are executed in the
interpreter's namespace (with the addition of the argument string).
It's just that calling happens through () operation.

> The normal way you make macros would be gone, too. Macros are made from commands
> that you've already executed, but $m_arg doesn't exist until you've made it into
> a macro. You might be able to implement your way around it, but you would be
> replacing one small special case (which isn't so special in the core1
> refactoring) into a bunch of special cases.

No, you would create the macro in the normal way. Then you %edit it
and %store it to "generalize", if you want. Say that you did an %imp
macro, you'll would probably test it like:

[~]|3> import os
[~]|4> reload(os)
   <4> <module 'os' from 'C:\Python25\lib\os.pyc'>
[~]|5> macro imp 3-4
Macro `imp` created. To execute, type its name (without quotes).
Macro contents:
import os
reload(os)

Then, you just do %edit imp, and replace 'os' with $m_arg everywhere.

Now, the only way to configure how a macro behaves is to alter global
variables which kinda sucks.

> Fernando and I had considered implementing macros by expanding them in the
> "translation" phase (a la autocall), but we rejected it for some reason.

Yeah, I also thought of expanding it in prefilter to
_ip.macrocall(mymacro) but just doing mymacro() is IMO cleaner. We
just need to pass the current ipapi object to the macro, and that's
something IpyAutocallMixin (IpyObjectMixin?) could do.

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From vivainio at gmail.com  Fri May  4 05:17:50 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Fri, 4 May 2007 11:17:50 +0200
Subject: [IPython-dev] prefilter reorg status
In-Reply-To: <db6b5ecc0705031251h7215ffecja8aea94798dfb695@mail.gmail.com>
References: <46cb515a0705031136hcc1d626w8aabbb16d8291ee3@mail.gmail.com>
	<db6b5ecc0705031251h7215ffecja8aea94798dfb695@mail.gmail.com>
Message-ID: <46cb515a0705040217k33ee626dx2caeaedaa77a81d1@mail.gmail.com>

On 5/3/07, Fernando Perez <fperez.net at gmail.com> wrote:

> At this point, it's probably worth starting to put this code into the
> new work branch.  Here we've put the results of this weekend's sprint:

If the code is already done for ipython trunk, why not put it there also?

I have to admit that I'm totally out of the loop regarding ipython1 -
I'd like to see a the advantages of cleaner codebase with the current
single-process ipython.

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From danmil at comcast.net  Fri May  4 09:50:52 2007
From: danmil at comcast.net (Dan Milstein)
Date: Fri, 4 May 2007 09:50:52 -0400
Subject: [IPython-dev] prefilter reorg status
In-Reply-To: <db6b5ecc0705031251h7215ffecja8aea94798dfb695@mail.gmail.com>
References: <46cb515a0705031136hcc1d626w8aabbb16d8291ee3@mail.gmail.com>
	<db6b5ecc0705031251h7215ffecja8aea94798dfb695@mail.gmail.com>
Message-ID: <2D3B7E3C-9A9D-4AA0-BA3A-6F0C6DFFB04B@comcast.net>

Gents,

Unfortunately, I've been a bit swamped, and I haven't had time to  
merge in that work.  I'm pretty sure I can make it happen early next  
week (sometime in Mon-Wed), and when I do, I'll go ahead and put it  
in the new work branch.

Sorry to be drawing this out...

-D

On May 3, 2007, at 3:51 PM, Fernando Perez wrote:

> On 5/3/07, Ville M. Vainio <vivainio at gmail.com> wrote:
>> Hi Dan,
>>
>> Care to post a status update of your prefilter cleanups? What  
>> actually
>> got in, what's their shape now etc.?
>>
>> I'd liko to dump any kind of cleanups you might still have into svn
>> just after 0.8.1, since I have some cleanups in that area in mind as
>> well.
>>
>> And sorry if the answer to this question should be obvious, it
>> happened on time when I had very little time for ipython.
>
> At this point, it's probably worth starting to put this code into the
> new work branch.  Here we've put the results of this weekend's sprint:
>
> http://projects.scipy.org/ipython/ipython/browser/ipython/branches/ 
> sprint1/ipython1/core1
>
> in particular, the above links to where the 'core' will go,
> effectively all the components that will make up what today's IPython
> is, but isolated into stnadalone entities that can be developed,
> tested and reused with more flexibility.
>
> The input filtering will go into the translator module, so I'd suggest
> Dan start hacking there.
>
> My intent is to keep the window of trunk+separate core as short as
> possible, so that sooner rather than later we can move everyone over
> and development effort isn't spread over two codebases.
>
> Obviously we'll still have users on trunk for a while, but if we can
> get this codebase to mature quickly, that period won't be too long.
>
> Cheers,
>
> f



From vivainio at gmail.com  Fri May  4 10:48:41 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Fri, 4 May 2007 16:48:41 +0200
Subject: [IPython-dev] prefilter reorg status
In-Reply-To: <2D3B7E3C-9A9D-4AA0-BA3A-6F0C6DFFB04B@comcast.net>
References: <46cb515a0705031136hcc1d626w8aabbb16d8291ee3@mail.gmail.com>
	<db6b5ecc0705031251h7215ffecja8aea94798dfb695@mail.gmail.com>
	<2D3B7E3C-9A9D-4AA0-BA3A-6F0C6DFFB04B@comcast.net>
Message-ID: <46cb515a0705040748y667a9e83x4f43161a072430f8@mail.gmail.com>

On 5/4/07, Dan Milstein <danmil at comcast.net> wrote:

> Unfortunately, I've been a bit swamped, and I haven't had time to
> merge in that work.  I'm pretty sure I can make it happen early next
> week (sometime in Mon-Wed), and when I do, I'll go ahead and put it
> in the new work branch.

Can you provide the patch for the stable ipython trunk as well?

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From danmil at comcast.net  Fri May  4 10:55:43 2007
From: danmil at comcast.net (Dan Milstein)
Date: Fri, 4 May 2007 10:55:43 -0400
Subject: [IPython-dev] prefilter reorg status
In-Reply-To: <46cb515a0705040748y667a9e83x4f43161a072430f8@mail.gmail.com>
References: <46cb515a0705031136hcc1d626w8aabbb16d8291ee3@mail.gmail.com>
	<db6b5ecc0705031251h7215ffecja8aea94798dfb695@mail.gmail.com>
	<2D3B7E3C-9A9D-4AA0-BA3A-6F0C6DFFB04B@comcast.net>
	<46cb515a0705040748y667a9e83x4f43161a072430f8@mail.gmail.com>
Message-ID: <34E0DCD8-CF53-47B7-B97C-0B9B32DF8450@comcast.net>

I *think* so.  I haven't been keeping up to date on how they've  
diverged.  I'll take a shot at that and let you know if there are any  
issues.

-D

On May 4, 2007, at 10:48 AM, Ville M. Vainio wrote:

> On 5/4/07, Dan Milstein <danmil at comcast.net> wrote:
>
>> Unfortunately, I've been a bit swamped, and I haven't had time to
>> merge in that work.  I'm pretty sure I can make it happen early next
>> week (sometime in Mon-Wed), and when I do, I'll go ahead and put it
>> in the new work branch.
>
> Can you provide the patch for the stable ipython trunk as well?
>
> -- 
> Ville M. Vainio - vivainio.googlepages.com
> blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'



From vivainio at gmail.com  Fri May  4 11:46:11 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Fri, 4 May 2007 17:46:11 +0200
Subject: [IPython-dev] prefilter reorg status
In-Reply-To: <34E0DCD8-CF53-47B7-B97C-0B9B32DF8450@comcast.net>
References: <46cb515a0705031136hcc1d626w8aabbb16d8291ee3@mail.gmail.com>
	<db6b5ecc0705031251h7215ffecja8aea94798dfb695@mail.gmail.com>
	<2D3B7E3C-9A9D-4AA0-BA3A-6F0C6DFFB04B@comcast.net>
	<46cb515a0705040748y667a9e83x4f43161a072430f8@mail.gmail.com>
	<34E0DCD8-CF53-47B7-B97C-0B9B32DF8450@comcast.net>
Message-ID: <46cb515a0705040846o47ce653fgd847ae7890a766ca@mail.gmail.com>

On 5/4/07, Dan Milstein <danmil at comcast.net> wrote:

> I *think* so.  I haven't been keeping up to date on how they've
> diverged.  I'll take a shot at that and let you know if there are any
> issues.

Great. The 0.8.1 should not be out before monday-tuesday, so there's no rush.

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From vivainio at gmail.com  Fri May  4 11:58:06 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Fri, 4 May 2007 17:58:06 +0200
Subject: [IPython-dev] 0.8.1 branch created in svn
Message-ID: <46cb515a0705040858k4ba55797x5405c635634f0638@mail.gmail.com>

I just branced trunk to

http://ipython.scipy.org/svn/ipython/ipython/branches/0.8.1/

not much should happen there anymore.

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From fperez.net at gmail.com  Fri May  4 15:34:50 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Fri, 4 May 2007 13:34:50 -0600
Subject: [IPython-dev] prefilter reorg status
In-Reply-To: <46cb515a0705040217k33ee626dx2caeaedaa77a81d1@mail.gmail.com>
References: <46cb515a0705031136hcc1d626w8aabbb16d8291ee3@mail.gmail.com>
	<db6b5ecc0705031251h7215ffecja8aea94798dfb695@mail.gmail.com>
	<46cb515a0705040217k33ee626dx2caeaedaa77a81d1@mail.gmail.com>
Message-ID: <db6b5ecc0705041234n70fbc610p5221d0af92abb582@mail.gmail.com>

On 5/4/07, Ville M. Vainio <vivainio at gmail.com> wrote:
> On 5/3/07, Fernando Perez <fperez.net at gmail.com> wrote:
>
> > At this point, it's probably worth starting to put this code into the
> > new work branch.  Here we've put the results of this weekend's sprint:
>
> If the code is already done for ipython trunk, why not put it there also?

In fact, if Dan already wrote the code, his patch will probabl apply
to trunk but not quite to ipython1/core1.  I modified the code quite a
bit, so it's likely that an as-is patch won't apply anymore.

> I have to admit that I'm totally out of the loop regarding ipython1 -
> I'd like to see a the advantages of cleaner codebase with the current
> single-process ipython.

It's important to note that we WILL have a single-process ipython
always, with no twisted dependencies.  It's just that it will be built
out of better separated (conceptually and code-wise) components, which
can then be reused to assemble multi-process ipythons, ones embedded
in GUIs or talking to their client over a network (in a web browser,
for example), etc.

One goal I'm after is that the actual engine will store the entire
session state, so that if you start it over a terminal but using 2
separate processes, you can disconnect a given terminal client and
reconnect from another terminal later, or from a network client,  and
continue working.  This ability to detach/reattach clients to an
engine will make a number of interesting use cases possible (remote
'live' collaboration, direct debugging of multiple engines when doing
distributed computing, etc.).

So having these abstractions will be very useful in the long run, even
if most users still end up with the single-terminal, single-process
client as their most common entry point.

Now the only challenge I see is for us to move quickly enough that our
trunk and dev efforts don't keep us spread too thin for too long.

Cheers,

f


From david.huard at gmail.com  Mon May  7 14:46:28 2007
From: david.huard at gmail.com (David Huard)
Date: Mon, 07 May 2007 14:46:28 -0400
Subject: [IPython-dev] bug with ??
Message-ID: <pan.2007.05.07.18.46.20.861773@gmail.com>

Hi, 

I get the following on Ubuntu running a Xeon processor. I noticed this
bug on a couple of other functions too, and unless I'm mistaken, it
appeared about one or two months ago. 


IPython 0.8.1 -- 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]: import numpy

In [2]: numpy.ma.maximum??
---------------------------------------------------------------------------
exceptions.TypeError                                 Traceback (most recent call last)

/usr/local/lib/python2.4/site-packages/IPython/iplib.py in multiline_prefilter(self, line, continue_prompt)
   2273         out = []
   2274         for l in line.rstrip('\n').split('\n'):
-> 2275             out.append(self._prefilter(l, continue_prompt))
   2276         return '\n'.join(out)
   2277 

/usr/local/lib/python2.4/site-packages/IPython/iplib.py in _prefilter(self, line, continue_prompt)
   2170             handler = self.esc_handlers.get(iFun[0:1])
   2171         if handler is not None:
-> 2172             return handler(line,continue_prompt,pre,iFun,theRest)
   2173         # Emacs ipython-mode tags certain input lines
   2174         if line.endswith('# PYTHON-MODE'):

/usr/local/lib/python2.4/site-packages/IPython/iplib.py in handle_help(self, line, continue_prompt, pre, iFun, theRest)
   2414             if line:
   2415                 #print 'line:<%r>' % line  # dbg
-> 2416                 self.magic_pinfo(line)
   2417             else:
   2418                 page(self.usage,screen_lines=self.rc.screen_length)

/usr/local/lib/python2.4/site-packages/IPython/Magic.py in magic_pinfo(self, parameter_s, namespaces)
    771         else:
    772             self._inspect('pinfo', oname, detail_level=detail_level,
--> 773                           namespaces=namespaces)
    774 
    775     def magic_psearch(self, parameter_s=''):

/usr/local/lib/python2.4/site-packages/IPython/Magic.py in _inspect(self, meth, oname, namespaces, **kw)
    705                 pmethod(info.obj,oname,formatter)
    706             elif meth == 'pinfo':
--> 707                 pmethod(info.obj,oname,formatter,info,**kw)
    708             else:
    709                 pmethod(info.obj,oname)

/usr/local/lib/python2.4/site-packages/IPython/OInspect.py in pinfo(self, obj, oname, formatter, info, detail_level)
    482                               'Calling definition not available.')
    483                 else:
--> 484                     out.write(header('Call def:\t')+self.format(call_def))
    485                 call_ds = getdoc(obj.__call__)
    486                 if call_ds:

TypeError: cannot concatenate 'str' and 'NoneType' objects

Cheers,
David




From vivainio at gmail.com  Mon May  7 14:52:32 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Mon, 7 May 2007 20:52:32 +0200
Subject: [IPython-dev] bug with ??
In-Reply-To: <pan.2007.05.07.18.46.20.861773@gmail.com>
References: <pan.2007.05.07.18.46.20.861773@gmail.com>
Message-ID: <46cb515a0705071152x63ca40b9wcf91f20c67322370@mail.gmail.com>

On 5/7/07, David Huard <david.huard at gmail.com> wrote:

> Hi,
>
> I get the following on Ubuntu running a Xeon processor. I noticed this
> bug on a couple of other functions too, and unless I'm mistaken, it
> appeared about one or two months ago.

Try with latest svn.

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From david.huard at gmail.com  Mon May  7 14:56:39 2007
From: david.huard at gmail.com (David Huard)
Date: Mon, 07 May 2007 14:56:39 -0400
Subject: [IPython-dev] bug with ??
References: <pan.2007.05.07.18.46.20.861773@gmail.com>
	<46cb515a0705071152x63ca40b9wcf91f20c67322370@mail.gmail.com>
Message-ID: <pan.2007.05.07.18.56.39.169233@gmail.com>

Le Mon, 07 May 2007 20:52:32 +0200, Ville M. Vainio a ?crit?:

> On 5/7/07, David Huard <david.huard at gmail.com> wrote:
> 
>> Hi,
>>
>> I get the following on Ubuntu running a Xeon processor. I noticed this
>> bug on a couple of other functions too, and unless I'm mistaken, it
>> appeared about one or two months ago.
> 
> Try with latest svn.

Fixed. 

Thanks. 



From danmil at comcast.net  Mon May  7 17:03:57 2007
From: danmil at comcast.net (Dan Milstein)
Date: Mon, 7 May 2007 17:03:57 -0400
Subject: [IPython-dev] Prefilter reorg ready for trunk
Message-ID: <DB04D6A3-3D69-42CF-8D5A-910818AFEE84@comcast.net>

Ville (and all),

So, I've got the prefilter cleanup all set for the trunk.  I do have  
svn access so I can commit it myself.  But, before I do that, I  
wanted to make sure this is a good time.  I've ported all my various  
tests and run those, but I don't know how much of the IPython  
universe those really cover, so I just wanted to ask first.

-Dan 


From danmil at comcast.net  Mon May  7 17:23:32 2007
From: danmil at comcast.net (Dan Milstein)
Date: Mon, 7 May 2007 17:23:32 -0400
Subject: [IPython-dev] Applying prefilter reorg to ipython1
In-Reply-To: <db6b5ecc0705041234n70fbc610p5221d0af92abb582@mail.gmail.com>
References: <46cb515a0705031136hcc1d626w8aabbb16d8291ee3@mail.gmail.com>
	<db6b5ecc0705031251h7215ffecja8aea94798dfb695@mail.gmail.com>
	<46cb515a0705040217k33ee626dx2caeaedaa77a81d1@mail.gmail.com>
	<db6b5ecc0705041234n70fbc610p5221d0af92abb582@mail.gmail.com>
Message-ID: <917817C3-0CD9-48A8-B0CE-D2FC82B12647@comcast.net>

F-

> In fact, if Dan already wrote the code, his patch will probabl apply
> to trunk but not quite to ipython1/core1.  I modified the code quite a
> bit, so it's likely that an as-is patch won't apply anymore.

This has, in fact, turned out to be true.

I *think* I see where my code now fits in (in core1/translator.py,  
essentially), but I have a question:

One of the main things I've got is a suite of tests which fairly  
exhaustively exercise the input transformation process.  Currently,  
they do so by creating an IPython instance, and feeding it various  
things, ala

import IPython
import IPython.ipapi

IPython.Shell.start()
ip = IPython.ipapi.get()

ip.runlines(...)


What is the equivalent in the new world?  Something like:

import core1.interpreter

interp = interpreter.Interpreter()
interp.execute(...)

Or am I even vaguely in the right territory?

-Dan


From robert.kern at gmail.com  Mon May  7 17:48:59 2007
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 07 May 2007 16:48:59 -0500
Subject: [IPython-dev] Applying prefilter reorg to ipython1
In-Reply-To: <917817C3-0CD9-48A8-B0CE-D2FC82B12647@comcast.net>
References: <46cb515a0705031136hcc1d626w8aabbb16d8291ee3@mail.gmail.com>	<db6b5ecc0705031251h7215ffecja8aea94798dfb695@mail.gmail.com>	<46cb515a0705040217k33ee626dx2caeaedaa77a81d1@mail.gmail.com>	<db6b5ecc0705041234n70fbc610p5221d0af92abb582@mail.gmail.com>
	<917817C3-0CD9-48A8-B0CE-D2FC82B12647@comcast.net>
Message-ID: <f1o6sd$67p$1@sea.gmane.org>

Dan Milstein wrote:
> F-
> 
>> In fact, if Dan already wrote the code, his patch will probabl apply
>> to trunk but not quite to ipython1/core1.  I modified the code quite a
>> bit, so it's likely that an as-is patch won't apply anymore.
> 
> This has, in fact, turned out to be true.
> 
> I *think* I see where my code now fits in (in core1/translator.py,  
> essentially), but I have a question:
> 
> One of the main things I've got is a suite of tests which fairly  
> exhaustively exercise the input transformation process.  Currently,  
> they do so by creating an IPython instance, and feeding it various  
> things, ala
> 
> import IPython
> import IPython.ipapi
> 
> IPython.Shell.start()
> ip = IPython.ipapi.get()
> 
> ip.runlines(...)
> 
> 
> What is the equivalent in the new world?  Something like:
> 
> import core1.interpreter
> 
> interp = interpreter.Interpreter()
> interp.execute(...)
> 
> Or am I even vaguely in the right territory?

Yes, but there is still other infrastructure (like magics) that is as-yet
unimplemented in core1, so you won't be able to rely on execution for testing.
Can you write tests that test *just* the translation and don't require
execution? That was one of the reasons we did the refactoring, to have cleanly
separated components that could be used and tested separately.

No one is using core1, yet, so you can check your stuff in there if you like,
and you and I can work together on how best to set up the tests.

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco



From vivainio at gmail.com  Tue May  8 02:26:04 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 8 May 2007 08:26:04 +0200
Subject: [IPython-dev] Prefilter reorg ready for trunk
In-Reply-To: <DB04D6A3-3D69-42CF-8D5A-910818AFEE84@comcast.net>
References: <DB04D6A3-3D69-42CF-8D5A-910818AFEE84@comcast.net>
Message-ID: <46cb515a0705072326j209bd11ah7377990e67d88e65@mail.gmail.com>

On 5/7/07, Dan Milstein <danmil at comcast.net> wrote:
> Ville (and all),
>
> So, I've got the prefilter cleanup all set for the trunk.  I do have
> svn access so I can commit it myself.  But, before I do that, I
> wanted to make sure this is a good time.  I've ported all my various
> tests and run those, but I don't know how much of the IPython
> universe those really cover, so I just wanted to ask first.

Don't do it yet. I branched for 0.8.1 already, but let's wait for a
word from fernando when he's ready for the release. Should be any time
now - today?

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From gael.varoquaux at normalesup.org  Tue May  8 12:09:28 2007
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 8 May 2007 18:09:28 +0200
Subject: [IPython-dev] instance docstring vs class docstring
Message-ID: <20070508160928.GA2115@clipper.ens.fr>

This is not real the right mailing list to ask this question, but as it
is ipython related I will go ahead...

If I have a module with code like this:

+++++++++++++++++++
class A(object):
    "A"
    pass

a = A()

a.__doc__="a"
+++++++++++++++++++

and I import it in ipython.

a? return the proper docstring (the instance's), but "help(a)" returns
the class's docstring.

Is there a way to avoid this inconvenient ? Do you think modifying
ipython's "help" function to workaround this would be a good idea ?

Cheers,

Ga?l


From vivainio at gmail.com  Tue May  8 12:14:20 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 8 May 2007 18:14:20 +0200
Subject: [IPython-dev] instance docstring vs class docstring
In-Reply-To: <20070508160928.GA2115@clipper.ens.fr>
References: <20070508160928.GA2115@clipper.ens.fr>
Message-ID: <46cb515a0705080914h67b02e5bj9a9333350309e4b0@mail.gmail.com>

On 5/8/07, Gael Varoquaux <gael.varoquaux at normalesup.org> wrote:

> This is not real the right mailing list to ask this question, but as it
> is ipython related I will go ahead...
>
> If I have a module with code like this:
>
> +++++++++++++++++++
> class A(object):
>     "A"
>     pass
>
> a = A()
>
> a.__doc__="a"
> +++++++++++++++++++
>
> and I import it in ipython.
>
> a? return the proper docstring (the instance's), but "help(a)" returns
> the class's docstring.

Why should we care so much about 'help', since we have ? and ??

?

As long as it doesn't crash...

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From gael.varoquaux at normalesup.org  Tue May  8 12:16:56 2007
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 8 May 2007 18:16:56 +0200
Subject: [IPython-dev] instance docstring vs class docstring
In-Reply-To: <46cb515a0705080914h67b02e5bj9a9333350309e4b0@mail.gmail.com>
References: <20070508160928.GA2115@clipper.ens.fr>
	<46cb515a0705080914h67b02e5bj9a9333350309e4b0@mail.gmail.com>
Message-ID: <20070508161656.GB2115@clipper.ens.fr>

On Tue, May 08, 2007 at 06:14:20PM +0200, Ville M. Vainio wrote:
> Why should we care so much about 'help', since we have ? and ??

Because many users still use them. These are the people I am worried
about.

Ga?l


From gael.varoquaux at normalesup.org  Tue May  8 12:41:30 2007
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Tue, 8 May 2007 18:41:30 +0200
Subject: [IPython-dev] Physical constants
Message-ID: <20070508164123.GC2115@clipper.ens.fr>

Hi all,

I have just coded an extention to the interactive physical quantities
allready in ipython (profile physics).

This is a module that defines a lot of physics constants, with units, to
be used in the ipython profile "physics". The rational behind this is
that instead of typing:

In [7]: c = 1 c

In [8]: c
Out[8]: 1 c

In [9]: c.inBaseUnits()
Out[9]: 2.998E+08 m/s

You directly can type:

In [10]: C.c
Out[10]: 2.998E+08 m/s

Thus you can use physcial constants in your calculations without creating
the constants.

I have added the following line in my ipythonrc-physics file:

"""
execute import constants as C
execute print '*** C is the physical constants module'
"""

I send the module to the ML and I propose for inclusion in ipython. The
module is most probably not complete. Additions are welcome.

    Ga?l
-------------- next part --------------
""" Module with physical constants for use with ipython, profile
"physics".

Definition of Fundamental Physical Constants, CODATA Recommended Values

Source, Peter J. Mohr and Barry N. Taylor,  
CODATA Recommended Values of the Fundamental
Physical Constants, 1998                    
                                            
Website: physics.nist.gov/constants         
"""
# License: BSD-like
# Copyright: Gael Varoquaux (gael.varoquaux at normalesup.org)

# inspired by maxima's physconst.mac by Cliff Yapp

#from math import * # math MUST be imported BEFORE PhysicalQInteractive 
from IPython.Extensions.PhysicalQInteractive import PhysicalQuantityInteractive

# Math constants:

# Pi mathematical constants
pi = 3.141592653589793238462643383279502884197169399375105820974944592

# Universal Constants
#-------------------------------------------------------------------------

c = PhysicalQuantityInteractive(299792458 , 'm/s')
c.__doc__ = """speed of light in vacuum"""
c.__doc__ = "speed of light in vacuum"

u_0 = PhysicalQuantityInteractive(4*pi*1E-7 , 'N/(A**2)')
u_0.__doc__ = """magnetic constant"""
mu_0 = PhysicalQuantityInteractive(4*pi*1E-7 , 'N/(A**2)')

epsilon_0 = PhysicalQuantityInteractive(8.854187817E-12 , 'F/m')
epsilon_0.__doc__ = """electric constant """

Z_0 = PhysicalQuantityInteractive(376.730313461 , 'ohm')
Z_0.__doc__ = """characteristic impedance of vacuum """

G = PhysicalQuantityInteractive(6.673E-11 , 'm**3/(kg*s**2)')
G.__doc__ = """Newtonian constant of gravitation    """


h = PhysicalQuantityInteractive(6.62606876E-34 , 'J*s')
h.__doc__ = """Planck constant    """


h_eV = PhysicalQuantityInteractive(4.13566727E-15 , 'eV*s')
h_eV.__doc__ = """Planck constant in eVs  """


h_bar = PhysicalQuantityInteractive(1.054571596E-34 , 'J*s')
h_bar.__doc__ = """Hbar"""


h_bar_eV = PhysicalQuantityInteractive(6.58211889E-16 , 'eV*s')
h_bar_eV.__doc__ = """Hbar in eV"""


P_m = PhysicalQuantityInteractive(2.1767E-8 , 'kg')
P_m.__doc__ = """Planck mass"""


P_l = PhysicalQuantityInteractive(1.6160E-35 , 'm')
P_l.__doc__ = """Planck length  """


P_t = PhysicalQuantityInteractive(5.3906E-44 , 's')
P_t.__doc__ = """Planck time """

# Electromagnetic Constants
#------------------------------------------------------------------------

_e = PhysicalQuantityInteractive(1.602176462E-19 , 'C')
_e.__doc__ = """elementary charge"""
q = _e


capitalphi_0 = PhysicalQuantityInteractive(2.067833636E-15 , 'Wb')
capitalphi_0.__doc__ = """magnetic flux quantum """
mfq_0 = PhysicalQuantityInteractive(2.067833636E-15 , 'Wb')


G_0 = PhysicalQuantityInteractive(7.748091696E-5 , 'S')
G_0.__doc__ = """conductance quantum """


K_J = PhysicalQuantityInteractive(483597.898E9 , 'Hz/V')
K_J.__doc__ = """Josephson constant"""


R_K = PhysicalQuantityInteractive(25812.807572 , 'ohm')
R_K.__doc__ = """von Klitzing constant"""


u_B = PhysicalQuantityInteractive(927.400899E-26 , 'J/T')
u_B.__doc__ = """Bohr magneton"""

ueVT_B = PhysicalQuantityInteractive(5.788381749E-5 , 'eV/T')
ueVT_B.__doc__ = """Bohr magneton in eV T-1"""


u_N = PhysicalQuantityInteractive(5.05078317E-27 , 'J/T')
u_N.__doc__ = """nuclear magneton """

ueVT_N = PhysicalQuantityInteractive(3.152451238E-8 , 'eV/T')
ueVT_N.__doc__ = """nuclear magneton in eV T-1      """

# Atomic and Nuclear Constants
# General
#-------------------------------------------------------------------------
# fine-structure constant 
alpha = 7.297352533E-3


Ry = PhysicalQuantityInteractive(10973731.568549 , '1/m')
Ry.__doc__ = """Rydberg constant  """
Ry_INF = PhysicalQuantityInteractive(10973731.568549 , '1/m')


a_0 = PhysicalQuantityInteractive(0.5291772083E-10 , 'm')
a_0.__doc__ = """Bohr radius """


E_h = PhysicalQuantityInteractive(4.35974381E-18 , 'J')
E_h.__doc__ = """Hartree energy """

Eev_h = PhysicalQuantityInteractive(27.2113834 , 'eV')
Eev_h.__doc__ = """Hartree energy in eV    """


qcir2 = PhysicalQuantityInteractive(3.636947516E-4 , 'm**2/s')
qcir2.__doc__ = """quantum of circulation   h/(2me) """

qcir = PhysicalQuantityInteractive(7.273895032E-4 , 'm**2/s')
qcir.__doc__ = """quantum of circulation   h/(me) """

# Electroweak
#-------------------------------------------------------------------------

Fcc = PhysicalQuantityInteractive(1.16639E-5 , '1/GeV**2')
Fcc.__doc__ = """Fermi coupling constant    """
# weak mixing angled  W (on-shell scheme)
wma_W = 0.2224

# Electron, e-
#-------------------------------------------------------------------------

m_e = PhysicalQuantityInteractive(9.10938188E-31 , 'kg')
m_e.__doc__ = """electron mass    """

m_e_u = PhysicalQuantityInteractive(5.485799110E-4 , 'amu')
m_e_u.__doc__ = """electron mass (electron relative atomic mass times amu)"""

me_J = PhysicalQuantityInteractive(8.18710414E-14 , 'J')
me_J.__doc__ = """electron mass - energy equivalent    """

me_MeV = PhysicalQuantityInteractive(0.510998902 , 'MeV')
me_MeV.__doc__ = """electron mass - energy equivalent in MeV"""

# electron-muon mass ratio
memu = 4.83633210E-3

# electron-tau mass ratio    
metau = 2.87555E-4

# electron-proton mass ratio    
memp = 5.446170232E-4

# electron-neutron mass ratio 
memn = 5.438673462E-4

# electron-deuteron mass ratio    
memd = 2.7244371170E-4

# electron to alpha particle mass ratio    
memalpha = 1.3709335611E-4


echargeemass = PhysicalQuantityInteractive(-1.758820174E11 , 'C/kg')
echargeemass.__doc__ = """electron charge to mass quotient    """


Molar_e = PhysicalQuantityInteractive(5.485799110E-7 , 'kg/mol')
Molar_e.__doc__ = """electron molar mass     """


lambdaC = PhysicalQuantityInteractive(2.426310215E-12 , 'm')
lambdaC.__doc__ = """Compton wavelength """


r_e = PhysicalQuantityInteractive(2.817940285E-15 , 'm')
r_e.__doc__ = """classical electron radius  """


sigma_e = PhysicalQuantityInteractive(0.665245854E-28 , 'm**2')
sigma_e.__doc__ = """Thomson cross section """


u_e = PhysicalQuantityInteractive(-928.476362E-26 , 'J/T')
u_e.__doc__ = """electron magnetic moment    """

# electron magnetic moment to Bohr magneton ratio     
ueuB = -1.0011596521869

# electron magnetic moment to nuclear magneton ratio    
ueuN = -1838.2819660

# electron magnetic moment anomaly |ue|/uB - 1    
a_e = 1.1596521869E-3

# electron g-factor 
g_e = -2.0023193043737

# electron-muon magnetic moment ratio   
ueuu = 206.7669720

# electron-proton magnetic moment ratio    
ueup = -658.2106875

# electron to shielded proton magnetic moment ratio  (H2O, sphere, 25  C)
ueusp = -658.2275954

# electron-neutron magnetic moment ratio    
ueun = 960.92050

# electron-deuteron magnetic moment ratio    
ueud = -2143.923498

# electron to shielded helione magnetic moment ratio  (gas, sphere, 25  C)
ueush = 864.058255


gamma_e = PhysicalQuantityInteractive(1.760859794E11 , '1/(s*T)')
gamma_e.__doc__ = """electron gyromagnetic ratio """

# Muon, u-
#-------------------------------------------------------------------------

m_u = PhysicalQuantityInteractive(1.88353109E-28 , 'kg')
m_u.__doc__ = """muon mass    """

mu_u = PhysicalQuantityInteractive(0.1134289168 , 'amu')
mu_u.__doc__ = """muon mass in muon relative atomic mass times amu    """


muc2_J = PhysicalQuantityInteractive(1.69283332E-11 , 'J')
muc2_J.__doc__ = """energy equivalent    """

muc2_MeV = PhysicalQuantityInteractive(105.6583568 , 'MeV')
muc2_MeV.__doc__ = """energy equivalent in MeV """

# muon-electron mass ratio    
mume = 206.7682657

# muon-tau mass ratio
mum = 5.94572E-2

# muon-proton mass ratio
mump = 0.1126095173

# muon-neutron mass ratio 
mumn = 0.1124545079


Molar_u = PhysicalQuantityInteractive(0.1134289168E-3 , 'kg/mol')
Molar_u.__doc__ = """muon molar mass """


lambda_C_u = PhysicalQuantityInteractive(11.73444197E-15 , 'm')
lambda_C_u.__doc__ = """muon Compton wavelength """


uu = PhysicalQuantityInteractive(-4.49044813E-26 , 'J/T')
uu.__doc__ = """muon magnetic moment    """

# ratio of muon magnetic moment to Bohr magneton ratio 
uuuB = -4.84197085E-3

# ratio of muon magnetic moment to nuclear magneton ratio    
uuuN = -8.89059770

# muon magnetic moment anomaly |uu|/(e /2mu) - 1    
a_u = 1.16591602E-3

# muon g-factor -2(1 + au)
g_u = -2.0023318320

# muon-proton magnetic moment ratio    
uuup = -3.18334539

# Tau, tau-
#-------------------------------------------------------------------------

m_tau = PhysicalQuantityInteractive(3.16788E-27 , 'kg')
m_tau.__doc__ = """tau mass    """

mu_tau = PhysicalQuantityInteractive(1.90774 , 'amu')
mu_tau.__doc__ = """tau mass  (tau relative atomic mass times amu)   """


mtauc2_J = PhysicalQuantityInteractive(2.84715E-10 , 'J')
mtauc2_J.__doc__ = """tau mass energy equivalent    """


mtauc2_MeV = PhysicalQuantityInteractive(1777.05 , 'MeV')
mtauc2_MeV.__doc__ = """tau mass energy equivalent in MeV """

# tau-electron mass ratio   
mtaume = 3477.60

# tau-muon mass ratio    
mtaumu = 16.8188

# tau-proton mass ratio    
mtaump = 1.89396

# tau-neutron mass ratio    
mtaumn = 1.89135


Molar_tau = PhysicalQuantityInteractive(1.90774E-3 , 'kg/mol')
Molar_tau.__doc__ = """tau molar mass """


lambda_C_tau = PhysicalQuantityInteractive(0.69770E-15 , 'm')
lambda_C_tau.__doc__ = """tau Compton wavelength    """

# Proton, p
#-------------------------------------------------------------------------

m_p = PhysicalQuantityInteractive(1.67262158E-27 , 'kg')
m_p.__doc__ = """proton mass  """

mu_p = PhysicalQuantityInteractive(1.00727646688 , 'amu')
mu_p.__doc__ = """proton mass (proton relative atomic mass times amu)  """


mpc2_J = PhysicalQuantityInteractive(1.50327731E-10 , 'J')
mpc2_J.__doc__ = """energy equivalent   """

mpc2_MeV = PhysicalQuantityInteractive(938.271998 , 'MeV')
mpc2_MeV.__doc__ = """energy equivalent in MeV  """

# proton-electron mass ratio 
mpme = 1836.1526675

# proton-muon mass ratio
mpmu = 8.88024408

# proton-tau mass ratio 
mpmtau = 0.527994

# proton-neutron mass ratio 
mpmn = 0.99862347855


emp = PhysicalQuantityInteractive(9.57883408E7 , 'C/kg')
emp.__doc__ = """proton charge to mass quotient    """


Molar_p = PhysicalQuantityInteractive(1.00727646688E-3 , 'kg/mol')
Molar_p.__doc__ = """proton molar mass """


lambda_C_p = PhysicalQuantityInteractive(1.321409847E-15 , 'm')
lambda_C_p.__doc__ = """proton Compton wavelength h/mpc  """


up = PhysicalQuantityInteractive(1.410606633E-26 , 'J/T')
up.__doc__ = """proton magnetic moment   """

# proton magnetic moment to Bohr magneton ratio 
upuB = 1.521032203E-3

# proton magnetic moment to nuclear magneton ratio 
upuN = 2.792847337

# proton g-factor 2up/uN  
g_p = 5.585694675

# proton-neutron magnetic moment ratio  
upun = -1.45989805


usp = PhysicalQuantityInteractive(1.410570399E-26 , 'J/T')
usp.__doc__ = """shielded proton magnetic moment  (H2O, sphere, 25  C)"""

# shielded proton magnetic moment to Bohr magneton ratio 
uspuB = 1.520993132E-3

# shielded proton magnetic moment to nuclear magneton ratio 
uspuN = 2.792775597

# proton magnetic shielding correction 1 - u p/up  (H2O, sphere, 25  C)
spc = 25.687E-6


gamma_p = PhysicalQuantityInteractive(2.67522212E8 , '1/(s*T)')
gamma_p.__doc__ = """proton gyromagnetic ratio """


gamma_sp = PhysicalQuantityInteractive(2.67515341E8 , '1/(s*T)')
gamma_sp.__doc__ = """shielded proton gyromagnetic ratio (H2O, sphere, 25  C)"""

# Neutron, n
#-------------------------------------------------------------------------

m_n = PhysicalQuantityInteractive(1.67492716E-27 , 'kg')
m_n.__doc__ = """neutron mass  """

mu_n = PhysicalQuantityInteractive(1.00866491578 , 'amu')
mu_n.__doc__ = """neutron mass (neutron relative atomic mass times amu) """


mnc2_J = PhysicalQuantityInteractive(1.50534946E-10 , 'J')
mnc2_J.__doc__ = """neutron mass energy equivalent  """


mnc2_MeV = PhysicalQuantityInteractive(939.565330 , 'MeV')
mnc2_MeV.__doc__ = """neutron mass energy equivalent  in MeV  """

# neutron-electron mass ratio 
mnme = 1838.6836550

# neutron-muon mass ratio 
mnmu = 8.89248478

# neutron-tau mass ratio 
mnm = 0.528722

# neutron-proton mass ratio 
mnmp = 1.00137841887


Molar_n = PhysicalQuantityInteractive(1.00866491578E-3 , 'kg/mol')
Molar_n.__doc__ = """neutron molar mass  """


lambda_C_n = PhysicalQuantityInteractive(1.319590898E-15 , 'm')
lambda_C_n.__doc__ = """neutron Compton wavelength"""


un = PhysicalQuantityInteractive(-0.96623640E-26 , 'J/T')
un.__doc__ = """neutron magnetic moment """

# neutron magnetic moment to Bohr magneton ratio 
unuB = -1.04187563E-3

# neutron magnetic moment to nuclear magneton ratio 
unuN = -1.91304272

# neutron g-factor 
g_n = -3.82608545

# neutron-electron magnetic moment ratio  
unue = 1.04066882E-3

# neutron-proton magnetic moment ratio 
unup = -0.68497934

# neutron to shielded proton magnetic moment ratio (H2O, sphere, 25  C)
unusp = -0.68499694


gamma_n = PhysicalQuantityInteractive(1.83247188E8 , '1/(s*T)')
gamma_n.__doc__ = """neutron gyromagnetic ratio """

# Deuteron, d
#-------------------------------------------------------------------------

m_d = PhysicalQuantityInteractive(3.34358309E-27 , 'kg')
m_d.__doc__ = """deuteron mass """


mu_d = PhysicalQuantityInteractive(2.01355321271 , 'amu')
mu_d.__doc__ = """deuteron mass (deuteron relative atomic mass times amu)  """


mdc2_J = PhysicalQuantityInteractive(3.00506262E-10 , 'J')
mdc2_J.__doc__ = """deuteron mass energy equivalent """


mdc2_eV = PhysicalQuantityInteractive(1875.612762 , 'MeV')
mdc2_eV.__doc__ = """deuteron mass energy equivalent in MeV  """

# deuteron-electron mass ratio  
mdme = 3670.4829550

# deuteron-proton mass ratio 
mdmp = 1.99900750083


Molar_d = PhysicalQuantityInteractive(2.01355321271E-3 , 'kg/mol')
Molar_d.__doc__ = """deuteron molar mass """


ud = PhysicalQuantityInteractive(0.433073457E-26 , 'J/T')
ud.__doc__ = """deuteron magnetic moment  """

# deuteron magnetic moment to Bohr magneton ratio 
uduB = 0.4669754556E-3

# deuteron magnetic moment to nuclear magneton ratio 
uduN = 0.8574382284

# deuteron-electron magnetic moment ratio 
udue = -4.664345537E-4

# deuteron-proton magnetic moment ratio 
udup = 0.3070122083

# deuteron-neutron magnetic moment ratio 
udun = -0.44820652

# Helion, h
#-------------------------------------------------------------------------

m_h = PhysicalQuantityInteractive(5.00641174E-27 , 'kg')
m_h.__doc__ = """helion mass """


mu_h = PhysicalQuantityInteractive(3.01493223469 , 'amu')
mu_h.__doc__ = """helion mass (helion relative atomic mass times amu)  """


mhc2_J = PhysicalQuantityInteractive(4.49953848E-10 , 'J')
mhc2_J.__doc__ = """helion mass energy equivalent """

mhc2_MeV = PhysicalQuantityInteractive(2808.39132 , 'MeV')
mhc2_MeV.__doc__ = """helion mass energy equivalent in MeV """

# helion-electron mass ratio 
mhme = 5495.885238

# helion-proton mass ratio 
mhmp = 2.99315265850


Molar_h = PhysicalQuantityInteractive(3.01493223469E-3 , 'kg/mol')
Molar_h.__doc__ = """helion molar mass """


ush = PhysicalQuantityInteractive(-1.074552967E-26 , 'J/T')
ush.__doc__ = """shielded helion magnetic moment (gas, sphere, 25  C)"""

# shielded helion magnetic moment to Bohr magneton ratio 
ushuB = -1.158671474E-3

# shielded helion magnetic moment to nuclear magneton ratio  
ushuN = -2.127497718

# shielded helion to proton magnetic moment ratio  (gas, sphere, 25  C)
ushup = -0.761766563

# shielded helion to shielded proton magnetic moment ratio  (gas/H2O, spheres, 25  C)
ushusp = -0.7617861313


gamma_h = PhysicalQuantityInteractive(2.037894764E8 , '1/(s*T)')
gamma_h.__doc__ = """shielded helion gyromagnetic  (gas, sphere, 25  C) """

# Alpha particle, 
#-------------------------------------------------------------------------

m_alpha = PhysicalQuantityInteractive(6.64465598E-27 , 'kg')
m_alpha.__doc__ = """alpha particle mass  """

mu_alpha = PhysicalQuantityInteractive(4.0015061747 , 'amu')
mu_alpha.__doc__ = """alpha particle mass (alpha particle relative atomic mass times amu) """


malphac2_J = PhysicalQuantityInteractive(5.97191897E-10 , 'J')
malphac2_J.__doc__ = """alpha particle mass energy equivalent  """


malphac2_MeV = PhysicalQuantityInteractive(3727.37904 , 'MeV')
malphac2_MeV.__doc__ = """alpha particle mass energy equivalent in MeV  """

# alpha particle to electron mass ratio 
malphame = 7294.299508

# alpha particle to proton mass ratio 
malphamp = 3.9725996846


Molar_alpha = PhysicalQuantityInteractive(4.0015061747E-3 , 'kg/mol')
Molar_alpha.__doc__ = """alpha particle molar mass"""

# PHYSICO-CHEMICAL
#-------------------------------------------------------------------------

N_A = PhysicalQuantityInteractive(6.02214199E23 , '1/mol')
N_A.__doc__ = """Avogadro constant  """
L = PhysicalQuantityInteractive(6.02214199E23 , '1/mol')


m_u = PhysicalQuantityInteractive(1.66053873E-27 , 'kg')
m_u.__doc__ = """atomic mass constant mu = 112m(12C) = 1 u = 10E-3 kg mol-1/NA"""
# atomic mass constant mu = 112m(12C) = 1 u = 10E-3 kg mol-1/NA
amu = m_u


muc2_J = PhysicalQuantityInteractive(1.49241778E-10 , 'J')
muc2_J.__doc__ = """energy equivalent of the atomic mass constant"""


muc2_MeV = PhysicalQuantityInteractive(931.494013 , 'MeV')
muc2_MeV.__doc__ = """energy equivalent of the atomic mass constant in MeV """


F = PhysicalQuantityInteractive(96485.3415 , 'C/mol')
F.__doc__ = """Faraday constant"""


N_Ah = PhysicalQuantityInteractive(3.990312689E-10 , 'J*s/mol')
N_Ah.__doc__ = """molar Planck constant   """


R = PhysicalQuantityInteractive(8.314472 , 'J/(mol*K)')
R.__doc__ = """molar gas constant  """


k_J = PhysicalQuantityInteractive(1.3806503E-23 , 'J/K')
k_J.__doc__ = """Boltzmann constant """


k_eV = PhysicalQuantityInteractive(8.617342E-5 , 'eV/K')
k_eV.__doc__ = """Boltzmann constant in eV """


n_0 = PhysicalQuantityInteractive(2.6867775E25 , '1/m**3')
n_0.__doc__ = """Loschmidt constant  NA/Vm """


Vm_1 = PhysicalQuantityInteractive(22.413996E-3 , 'm**3/mol')
Vm_1.__doc__ = """molar volume of ideal gas RT/p   T = 273.15 K, p = 101.325 kPa """

Vm_2 = PhysicalQuantityInteractive(22.710981E-3 , 'm**3/mol')
Vm_2.__doc__ = """molar volume of ideal gas RT/p   T = 273.15 K, p = 100 kPa  """

# Sackur-Tetrode constant (absolute entropy constant) 52 + ln_(2 mukT1/h2)3/2kT1/p0
# T1 = 1 K, p0 = 100 kPa 
S_0R_1 = -1.1517048
# T1 = 1 K, p0 = 101.325 kPa  
S_0R_2 = -1.1648678


sigma = PhysicalQuantityInteractive(5.670400E-8 , 'W/(m**2*K**4)')
sigma.__doc__ = """Stefan-Boltzmann constant """


c_1 = PhysicalQuantityInteractive(3.74177107E-16 , 'W*m**2')
c_1.__doc__ = """first radiation constant"""


c_1L = PhysicalQuantityInteractive(1.191042722E-16 , 'W*m**2/sr')
c_1L.__doc__ = """first radiation constant for spectral radiance"""


c_2 = PhysicalQuantityInteractive(1.4387752E-2 , 'm*K')
c_2.__doc__ = """second radiation constant"""


b = PhysicalQuantityInteractive(2.8977686E-3 , 'm*K')
b.__doc__ = """Wien displacement law constant b =  maxT = c2/4.965 114231... """


From dfj225 at gmail.com  Tue May  8 12:57:51 2007
From: dfj225 at gmail.com (Doug Jones)
Date: Tue, 8 May 2007 12:57:51 -0400
Subject: [IPython-dev] visualization with parallel ipython
Message-ID: <1315be7e0705080957n6d1d0937ha146ec314ca66bcb@mail.gmail.com>

Hello IPython devs,

I've recently been looking at visualization of parallel data sets and
have started to consider the possibilities for this type of
visualization when the data is distributed within IPython1.

What I'm wondering is, if a user would like to visualize on their
desktop or laptop and the data has been spread over many nodes using
IPython1, how easy or difficult would it be to visualize this data
using tools with Python interfaces.

I suppose my main concern is moving the data from nodes to the user's
machine. I know before I was told that IPython1 had issues when trying
to move data that was on the order of 100MB. Is this still an issue?

Are there any users of IPython that currently do visualization of
parallel data sets? If so, do you know what tools they find useful?

It seems that in serial environments pylab and mayavi are popular
choices, so it might be likely that users want to use these packages
in a parallel environment.

Forgive my ignorance, but I am not really familiar with pylab or
mayavi, but I'm hoping a flow similar to this would be feasible for
these packages.

One IPython1 node collects the data necessary for the plot.
This node uses a visualization package to produce the plot or
visualization (a graph or geometry).
This resulting visualization is serialized and sent to the client.
The client can then view and further manipulate using a plotting tool
on their desktop machine.

On a side note, there was the announcement that IPython1 "saw" was now
in the alpha stage. How far away is this from being considered
"stable". I'm not really looking to use this in a production
environment or anything like that. Instead I'm hoping to deploy it
locally for my own development uses and also the use of a few
testers/users of the system.

Thank you,
~Doug


From prabhu at aero.iitb.ac.in  Tue May  8 13:33:01 2007
From: prabhu at aero.iitb.ac.in (Prabhu Ramachandran)
Date: Tue, 8 May 2007 23:03:01 +0530
Subject: [IPython-dev] visualization with parallel ipython
In-Reply-To: <1315be7e0705080957n6d1d0937ha146ec314ca66bcb@mail.gmail.com>
References: <1315be7e0705080957n6d1d0937ha146ec314ca66bcb@mail.gmail.com>
Message-ID: <17984.46157.565495.238960@gargle.gargle.HOWL>

>>>>> "Doug" == Doug Jones <dfj225 at gmail.com> writes:

    Doug> Are there any users of IPython that currently do
    Doug> visualization of parallel data sets? If so, do you know what
    Doug> tools they find useful?

I don't do any parallel visualization but do know that VTK does
support parallel processing via MPI.  It is probably not very Pythonic
an approach though.  Kitware also has a powerful open source tool
called ParaView that does parallel visualization.  While paraview is
very powerful I am not sure that it is very Python friendly in the
sense that it integrates with numpy/ipython very well.

    Doug> It seems that in serial environments pylab and mayavi are
    Doug> popular choices, so it might be likely that users want to
    Doug> use these packages in a parallel environment.

    Doug> Forgive my ignorance, but I am not really familiar with
    Doug> pylab or mayavi, but I'm hoping a flow similar to this would
    Doug> be feasible for these packages.

I think this might be feasible but it is a good idea to look at what
VTK/ParaView do and learn from that before doing any work in this
direction.  If you have mayavi related questions in this direction
answered please post to enthought-dev at mail.enthought.com or
mayavi-users at lists.sourceforge.net and I'll try and respond.

    Doug> One IPython1 node collects the data necessary for the plot.
    Doug> This node uses a visualization package to produce the plot
    Doug> or visualization (a graph or geometry).  This resulting
    Doug> visualization is serialized and sent to the client.  The
    Doug> client can then view and further manipulate using a plotting
    Doug> tool on their desktop machine.

Yes, this is what I think is done in ParaView.  2D is a lot easier but
3D is harder and AFAIK ParaView uses a library called IceT to do the
composting of the final image that is rendered on screen.

HTH.

cheers,
prabhu


From gakusei at dakotacom.net  Tue May  8 20:27:40 2007
From: gakusei at dakotacom.net (Paul Mueller)
Date: Tue, 8 May 2007 17:27:40 -0700
Subject: [IPython-dev] Patch to fix string exceptions raised by DPyGetOpt.py
Message-ID: <20070509002739.GA5111@localhost.localdomain>

Hi,

There are some string exceptions in IPython/DPyGetOpt.py (in r2314), some of
which are raised when passing bad options to ipython on the command line. Since
string exceptions are deprecated in python 2.5, this raises a
DeprecationWarning (usage message redirected to /dev/null for clarity):

~/src/mods/ipython> ./ipython.py --badopt >/dev/null
/home/yuurei/src/mods/ipython/IPython/DPyGetOpt.py:532: DeprecationWarning: raising a string exception is deprecated
  raise arg_error, 'Illegal option \'' + arg + '\''
WARNING:
Error in Arguments: "Illegal option '--badopt'"

I've attached a patch that fixes this by using exception classes
instead. It also modifies IPython/ipmaker.py and IPython/genutils.py
to catch only the new ArgumentError exception when calling
getopt.processArguments(), as other exceptions indicate errors in DPyGetOpt for
which a crash report should be generated.

The patch also removes uses of sys.exc_value, which is also deprecated.

The _test() function in DPyGetOpt.py produces the same output as it did before
the patch (other than the deprecation warnings, of course).

I've also grepped the rest of ipython, and there appear to be no other string
exceptions.

Paul Mueller
-------------- next part --------------
Index: IPython/genutils.py
===================================================================
--- IPython/genutils.py	(revision 2314)
+++ IPython/genutils.py	(working copy)
@@ -601,9 +601,9 @@
 
     try:
         getopt.processArguments(argv)
-    except:
+    except DPyGetOpt.ArgumentError, exc:
         print usage
-        warn(`sys.exc_value`,level=4)
+        warn('"%s"' % exc,level=4)
 
     defaults.update(getopt.optionValues)
     args = getopt.freeValues
Index: IPython/DPyGetOpt.py
===================================================================
--- IPython/DPyGetOpt.py	(revision 2314)
+++ IPython/DPyGetOpt.py	(working copy)
@@ -74,10 +74,19 @@
 import sys
 import types
 
-arg_error  = 'DPyGetOpt Argument Error'
-spec_error = 'DPyGetOpt Specification Error'
-term_error = 'DPyGetOpt Termination Error'
+class Error(Exception):
+    """Base class for exceptions in the DPyGetOpt module."""
 
+class ArgumentError(Error):
+    """Exception indicating an error in the arguments passed to
+    DPyGetOpt.processArguments."""
+
+class SpecificationError(Error):
+    """Exception indicating an error with an option specification."""
+
+class TerminationError(Error):
+    """Exception indicating an error with an option processing terminator."""
+
 specificationExpr = re.compile('(?P<required>.)(?P<type>.)(?P<multi>@?)')
 
 ArgRequired     = 'Requires an Argument'
@@ -214,7 +223,7 @@
         """
         Adds the option described by oTuple (name, (type, mode,
         default), alias) to optionTuples.  Adds index keyed under name
-        to optionNames.  Raises spec_error if name already in
+        to optionNames.  Raises SpecificationError if name already in
         optionNames
         """
         (name, (type, mode, default, multi), realName) = oTuple
@@ -222,11 +231,13 @@
         # verify name and add to option names dictionary
         if self.optionNames.has_key(name):
             if realName:
-                raise spec_error, 'Alias \'' + name + '\' for \'' + realName + \
-                                '\' already used for another option or alias.'
+                raise SpecificationError('Alias \'' + name + '\' for \'' +
+                                         realName +
+                                         '\' already used for another option or alias.')
             else:
-                raise spec_error, 'Option named \'' + name + \
-                                '\' specified more than once. Specification: ' + option
+                raise SpecificationError('Option named \'' + name +
+                                         '\' specified more than once. Specification: '
+                                         + option)
 
         # validated. add to optionNames
         self.optionNames[name] = self.tupleIndex
@@ -244,11 +255,13 @@
             # verify name and add to option names dictionary
             if self.optionNames.has_key(alias):
                 if realName:
-                    raise spec_error, 'Negated alias \'' + name + '\' for \'' + realName + \
-                                    '\' already used for another option or alias.'
+                    raise SpecificationError('Negated alias \'' + name +
+                                             '\' for \'' + realName +
+                                             '\' already used for another option or alias.')
                 else:
-                    raise spec_error, 'Negated option named \'' + name + \
-                                    '\' specified more than once. Specification: ' + option
+                    raise SpecificationError('Negated option named \'' + name +
+                                             '\' specified more than once. Specification: '
+                                             + option)
 
             # validated. add to optionNames
             self.optionNames[alias] = self.tupleIndex
@@ -299,7 +312,8 @@
             # break into names, specification
             match = splitExpr.match(option)
             if match is None:
-                raise spec_error, 'Invalid specification {' + option + '}'
+                raise SpecificationError('Invalid specification {' + option +
+                                         '}')
 
             names                     = match.group('names')
             specification = match.group('spec')
@@ -328,7 +342,8 @@
                 match = specificationExpr.match(specification)
                 if match is None:
                     # failed to parse, die
-                    raise spec_error, 'Invalid configuration for option \'' + option + '\''
+                    raise SpecificationError('Invalid configuration for option \''
+                                             + option + '\'')
 
                 # determine mode
                 required = match.group('required')
@@ -337,7 +352,8 @@
                 elif required == ':':
                     argMode = ArgOptional
                 else:
-                    raise spec_error, 'Unknown requirement configuration \'' + required + '\''
+                    raise SpecificationError('Unknown requirement configuration \''
+                                             + required + '\'')
 
                 # determine type
                 type = match.group('type')
@@ -351,7 +367,8 @@
                     argType   = RealArgType
                     argDefault = 1
                 else:
-                    raise spec_error, 'Unknown type specifier \'' + type + '\''
+                    raise SpecificationError('Unknown type specifier \'' +
+                                             type + '\'')
 
                 # determine quantity
                 if match.group('multi') == '@':
@@ -425,7 +442,7 @@
         terminator.  If it is, sets self.terminator to the full name of
         the terminator.
 
-        If more than one terminator matched, raises a term_error with a
+        If more than one terminator matched, raises a TerminationError with a
         string describing the ambiguity.
         """
 
@@ -445,8 +462,8 @@
         if not len(terms):
             return None
         elif len(terms) > 1:
-            raise term_error, 'Ambiguous terminator \'' + optionName + \
-                            '\' matches ' + repr(terms)
+            raise TerminationError('Ambiguous terminator \'' + optionName +
+                                   '\' matches ' + repr(terms))
 
         self.terminator = terms[0]
         return self.terminator
@@ -529,10 +546,11 @@
             tuples = self._getArgTuple(optName)
 
             if tuples == None:
-                raise arg_error, 'Illegal option \'' + arg + '\''
+                raise ArgumentError('Illegal option \'' + arg + '\'')
             elif len(tuples) > 1:
-                raise arg_error, 'Ambiguous option \'' + arg + '\';  matches ' + \
-                                repr(map(lambda x: x[0], tuples))
+                raise ArgumentError('Ambiguous option \'' + arg +
+                                    '\';  matches ' +
+                                    repr(map(lambda x: x[0], tuples)))
             else:
                 config = tuples[0]
 
@@ -545,8 +563,9 @@
             if (optMode == ArgRequired):
                 if (not nextArg) or self._isTerminator(nextArg):
 #                                       print nextArg
-                    raise arg_error, 'Option \'' + arg + \
-                                    '\' requires an argument of type ' + optType
+                    raise ArgumentError('Option \'' + arg +
+                                        '\' requires an argument of type ' +
+                                        optType)
 
             if (not optMode == None) and nextArg and (not self._isTerminator(nextArg)):
                 # nextArg defined, option configured to possibly consume arg
@@ -559,15 +578,17 @@
                     except:
                         # only raise conversion error if REQUIRED to consume argument
                         if optMode == ArgRequired:
-                            raise arg_error, 'Invalid argument to option \'' + arg + \
-                                            '\';  should be \'' + optType + '\''
+                            raise ArgumentError('Invalid argument to option \''
+                                                + arg + '\';  should be \'' +
+                                                optType + '\'')
                         else:
                             optionValue = optDefault
-                except arg_error:
-                    raise arg_error, sys.exc_value
+                except ArgumentError:
+                    raise
                 except:
-                    raise arg_error, '(' + arg + \
-                                    ') Conversion function for \'' + optType + '\' not found.'
+                    raise ArgumentError('(' + arg +
+                                        ') Conversion function for \'' +
+                                        optType + '\' not found.')
             else:
                 optionValue = optDefault
 
@@ -583,7 +604,8 @@
             else:
                 # only one value per
                 if self.isPosixCompliant and self.optionValues.has_key(realName):
-                    raise arg_error, 'Argument \'' + arg + '\' occurs multiple times.'
+                    raise ArgumentError('Argument \'' + arg +
+                                        '\' occurs multiple times.')
 
                 self.optionValues[realName] = optionValue
 
@@ -610,25 +632,25 @@
     """
     try:
         DPyGetOpt(['foo', 'bar=s', 'foo'])
-    except:
-        print 'EXCEPTION (should be \'foo\' already used..): ' + sys.exc_value
+    except Error, exc:
+        print 'EXCEPTION (should be \'foo\' already used..): %s' % exc
 
     try:
         DPyGetOpt(['foo|bar|apple=s@', 'baz|apple!'])
-    except:
-        print 'EXCEPTION (should be duplicate alias/name error): ' + sys.exc_value
+    except Error, exc:
+        print 'EXCEPTION (should be duplicate alias/name error): %s' % exc
 
     x = DPyGetOpt(['apple|atlas=i@', 'application|executable=f@'])
     try:
         x.processArguments(['-app', '29.3'])
-    except:
-        print 'EXCEPTION (should be ambiguous argument): ' +    sys.exc_value
+    except Error, exc:
+        print 'EXCEPTION (should be ambiguous argument): %s' % exc
 
     x = DPyGetOpt(['foo'], ['antigravity', 'antithesis'])
     try:
         x.processArguments(['-foo', 'anti'])
-    except:
-        print 'EXCEPTION (should be ambiguous terminator): ' + sys.exc_value
+    except Error, exc:
+        print 'EXCEPTION (should be ambiguous terminator): %s' % exc
 
     profile = ['plain-option',
                               'boolean-option!',
Index: IPython/ipmaker.py
===================================================================
--- IPython/ipmaker.py	(revision 2314)
+++ IPython/ipmaker.py	(working copy)
@@ -299,9 +299,9 @@
 
     try:
         getopt.processArguments(argv)
-    except:
+    except DPyGetOpt.ArgumentError, exc:
         print cmd_line_usage
-        warn('\nError in Arguments: ' + `sys.exc_value`)
+        warn('\nError in Arguments: "%s"' % exc)
         sys.exit(1)
 
     # convert the options dict to a struct for much lighter syntax later

From fperez.net at gmail.com  Wed May  9 01:12:25 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 8 May 2007 23:12:25 -0600
Subject: [IPython-dev] Prefilter reorg ready for trunk
In-Reply-To: <46cb515a0705072326j209bd11ah7377990e67d88e65@mail.gmail.com>
References: <DB04D6A3-3D69-42CF-8D5A-910818AFEE84@comcast.net>
	<46cb515a0705072326j209bd11ah7377990e67d88e65@mail.gmail.com>
Message-ID: <db6b5ecc0705082212k18a29356k214d3a4983c34da@mail.gmail.com>

On 5/8/07, Ville M. Vainio <vivainio at gmail.com> wrote:


> Don't do it yet. I branched for 0.8.1 already, but let's wait for a
> word from fernando when he's ready for the release. Should be any time
> now - today?

I'm afraid not until we hear from Walter on this one:

http://projects.scipy.org/ipython/ipython/ticket/152

I just discovered it today when testing the release with a mock
install, to make sure everything was in the right place.  Other than
this, I'm willing to put 0.8.1 out as it is.  Feel free to go ahead
and merge into trunk the patches and other things that have been sent
in, we'll cut the release from the 0.8.1 branch and will make a tag at
that point.  This little patch can then be backported to trunk.

Walter?

Cheers,

f


From walter at livinglogic.de  Wed May  9 04:15:56 2007
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Wed, 09 May 2007 10:15:56 +0200
Subject: [IPython-dev] Prefilter reorg ready for trunk
In-Reply-To: <db6b5ecc0705082212k18a29356k214d3a4983c34da@mail.gmail.com>
References: <DB04D6A3-3D69-42CF-8D5A-910818AFEE84@comcast.net>	<46cb515a0705072326j209bd11ah7377990e67d88e65@mail.gmail.com>
	<db6b5ecc0705082212k18a29356k214d3a4983c34da@mail.gmail.com>
Message-ID: <4641833C.5040008@livinglogic.de>

Fernando Perez wrote:
> On 5/8/07, Ville M. Vainio <vivainio at gmail.com> wrote:
> 
> 
>> Don't do it yet. I branched for 0.8.1 already, but let's wait for a
>> word from fernando when he's ready for the release. Should be any time
>> now - today?
> 
> I'm afraid not until we hear from Walter on this one:
> 
> http://projects.scipy.org/ipython/ipython/ticket/152
> 
> I just discovered it today when testing the release with a mock
> install, to make sure everything was in the right place.  Other than
> this, I'm willing to put 0.8.1 out as it is.  Feel free to go ahead
> and merge into trunk the patches and other things that have been sent
> in, we'll cut the release from the 0.8.1 branch and will make a tag at
> that point.  This little patch can then be backported to trunk.
> 
> Walter?

The help files igrid_help.css and igrid_help.html were supposed to be 
installed in the same directory as igrid.py itself, because igrid.py 
uses the following code to find the file:

filename = os.path.join(os.path.dirname(__file__), "igrid_help.html")

How would this work, if the files were put into the doc directory?

Servus,
    Walter


From vivainio at gmail.com  Wed May  9 15:54:40 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 9 May 2007 21:54:40 +0200
Subject: [IPython-dev] Prefilter reorg ready for trunk
In-Reply-To: <4641833C.5040008@livinglogic.de>
References: <DB04D6A3-3D69-42CF-8D5A-910818AFEE84@comcast.net>
	<46cb515a0705072326j209bd11ah7377990e67d88e65@mail.gmail.com>
	<db6b5ecc0705082212k18a29356k214d3a4983c34da@mail.gmail.com>
	<4641833C.5040008@livinglogic.de>
Message-ID: <46cb515a0705091254r6d9b49a9w28e576ee19e2bad0@mail.gmail.com>

On 5/9/07, Walter D?rwald <walter at livinglogic.de> wrote:

> The help files igrid_help.css and igrid_help.html were supposed to be
> installed in the same directory as igrid.py itself, because igrid.py
> uses the following code to find the file:
>
> filename = os.path.join(os.path.dirname(__file__), "igrid_help.html")
>
> How would this work, if the files were put into the doc directory?

I don't think we should try to fix this for 0.8.1. Just leave the
"html help" menu item broken (it's strictly not needed, right?), and
put the help files in doc directory. We can fix the menu item later.

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From walter at livinglogic.de  Wed May  9 16:32:55 2007
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Wed, 09 May 2007 22:32:55 +0200
Subject: [IPython-dev] Prefilter reorg ready for trunk
In-Reply-To: <46cb515a0705091254r6d9b49a9w28e576ee19e2bad0@mail.gmail.com>
References: <DB04D6A3-3D69-42CF-8D5A-910818AFEE84@comcast.net>	
	<46cb515a0705072326j209bd11ah7377990e67d88e65@mail.gmail.com>	
	<db6b5ecc0705082212k18a29356k214d3a4983c34da@mail.gmail.com>	
	<4641833C.5040008@livinglogic.de>
	<46cb515a0705091254r6d9b49a9w28e576ee19e2bad0@mail.gmail.com>
Message-ID: <46422FF7.1060800@livinglogic.de>

Ville M. Vainio wrote:
> On 5/9/07, Walter D?rwald <walter at livinglogic.de> wrote:
> 
>> The help files igrid_help.css and igrid_help.html were supposed to be
>> installed in the same directory as igrid.py itself, because igrid.py
>> uses the following code to find the file:
>>
>> filename = os.path.join(os.path.dirname(__file__), "igrid_help.html")
>>
>> How would this work, if the files were put into the doc directory?
> 
> I don't think we should try to fix this for 0.8.1. Just leave the
> "html help" menu item broken (it's strictly not needed, right?),

True, you can always open the HTML file yourself in your browser.

> and
> put the help files in doc directory. We can fix the menu item later.

Another solution would be to put the HTML as a string into igrid.py 
itself, but then it will no longer work in a standalone browser.

Servus,
    Walter



From vivainio at gmail.com  Wed May  9 17:10:05 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 9 May 2007 23:10:05 +0200
Subject: [IPython-dev] Prefilter reorg ready for trunk
In-Reply-To: <46422FF7.1060800@livinglogic.de>
References: <DB04D6A3-3D69-42CF-8D5A-910818AFEE84@comcast.net>
	<46cb515a0705072326j209bd11ah7377990e67d88e65@mail.gmail.com>
	<db6b5ecc0705082212k18a29356k214d3a4983c34da@mail.gmail.com>
	<4641833C.5040008@livinglogic.de>
	<46cb515a0705091254r6d9b49a9w28e576ee19e2bad0@mail.gmail.com>
	<46422FF7.1060800@livinglogic.de>
Message-ID: <46cb515a0705091410q62e61733k5358b903cb676342@mail.gmail.com>

On 5/9/07, Walter D?rwald <walter at livinglogic.de> wrote:

> Another solution would be to put the HTML as a string into igrid.py
> itself, but then it will no longer work in a standalone browser.

I think we should just leave it out of the igrid.py file, i.e. put in
fernando's patch, leave the menu button broken and get 0.8.1 released
(with the fixed pyreadline). Finally :-)

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From fperez.net at gmail.com  Wed May  9 17:35:46 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 9 May 2007 15:35:46 -0600
Subject: [IPython-dev] Prefilter reorg ready for trunk
In-Reply-To: <46cb515a0705091410q62e61733k5358b903cb676342@mail.gmail.com>
References: <DB04D6A3-3D69-42CF-8D5A-910818AFEE84@comcast.net>
	<46cb515a0705072326j209bd11ah7377990e67d88e65@mail.gmail.com>
	<db6b5ecc0705082212k18a29356k214d3a4983c34da@mail.gmail.com>
	<4641833C.5040008@livinglogic.de>
	<46cb515a0705091254r6d9b49a9w28e576ee19e2bad0@mail.gmail.com>
	<46422FF7.1060800@livinglogic.de>
	<46cb515a0705091410q62e61733k5358b903cb676342@mail.gmail.com>
Message-ID: <db6b5ecc0705091435o6bdf5218lc55dc9472528e20b@mail.gmail.com>

On 5/9/07, Ville M. Vainio <vivainio at gmail.com> wrote:
> On 5/9/07, Walter D?rwald <walter at livinglogic.de> wrote:
>
> > Another solution would be to put the HTML as a string into igrid.py
> > itself, but then it will no longer work in a standalone browser.
>
> I think we should just leave it out of the igrid.py file, i.e. put in
> fernando's patch, leave the menu button broken and get 0.8.1 released
> (with the fixed pyreadline). Finally :-)

Walter?  Since this is your baby, I'd like to hear your opinion before
taking action.  Keeping both branches open for much longer is a
distraction, so we should certainly take action quickly.  But if you
feel this is a really important fix, go ahead and do something like

html_help = """
COPY-PASTE your text here.
"""

for now as a stop-gap measure, and we can keep the actual html file in
the doc/ directory as per my patch.  With that, the help will work
both within the wx igrid tool and from an external browser, and you
can later work on a cleaner solution for the long term.

Otherwise, we just go as proposed by Ville with my patch and leave
this for post-0.8.1


cheers,

f


From walter at livinglogic.de  Wed May  9 19:11:09 2007
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Thu, 10 May 2007 01:11:09 +0200
Subject: [IPython-dev] Prefilter reorg ready for trunk
In-Reply-To: <db6b5ecc0705091435o6bdf5218lc55dc9472528e20b@mail.gmail.com>
References: <DB04D6A3-3D69-42CF-8D5A-910818AFEE84@comcast.net>	
	<46cb515a0705072326j209bd11ah7377990e67d88e65@mail.gmail.com>	
	<db6b5ecc0705082212k18a29356k214d3a4983c34da@mail.gmail.com>	
	<4641833C.5040008@livinglogic.de>	
	<46cb515a0705091254r6d9b49a9w28e576ee19e2bad0@mail.gmail.com>	
	<46422FF7.1060800@livinglogic.de>	
	<46cb515a0705091410q62e61733k5358b903cb676342@mail.gmail.com>
	<db6b5ecc0705091435o6bdf5218lc55dc9472528e20b@mail.gmail.com>
Message-ID: <4642550D.5010602@livinglogic.de>

Fernando Perez wrote:
> On 5/9/07, Ville M. Vainio <vivainio at gmail.com> wrote:
>> On 5/9/07, Walter D?rwald <walter at livinglogic.de> wrote:
>>
>> > Another solution would be to put the HTML as a string into igrid.py
>> > itself, but then it will no longer work in a standalone browser.
>>
>> I think we should just leave it out of the igrid.py file, i.e. put in
>> fernando's patch, leave the menu button broken and get 0.8.1 released
>> (with the fixed pyreadline). Finally :-)
> 
> Walter?  Since this is your baby, I'd like to hear your opinion before
> taking action.  Keeping both branches open for much longer is a
> distraction, so we should certainly take action quickly.  But if you
> feel this is a really important fix, go ahead and do something like
> 
> html_help = """
> COPY-PASTE your text here.
> """
> 
> for now as a stop-gap measure,

Done (the menu item "Show help in browser" is still broken though).

> and we can keep the actual html file in
> the doc/ directory as per my patch.

OK, go ahead and apply your patch.

> With that, the help will work
> both within the wx igrid tool and from an external browser, and you
> can later work on a cleaner solution for the long term.
>
> Otherwise, we just go as proposed by Ville with my patch and leave
> this for post-0.8.1

Nik as a few pending patches for igrid (a few new commands etc.). We'll 
check those in, once 0.8.1 is out the door.

Servus,
    Walter


From fperez.net at gmail.com  Thu May 10 01:55:55 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 9 May 2007 23:55:55 -0600
Subject: [IPython-dev] Physical constants
In-Reply-To: <20070508164123.GC2115@clipper.ens.fr>
References: <20070508164123.GC2115@clipper.ens.fr>
Message-ID: <db6b5ecc0705092255k2c21c4a0kabea9cd94333434@mail.gmail.com>

Thanks!  Ville added it into the 0.8.1 branch, from which I just
uploaded the release a moment ago.

I also put it into trunk myself just now, so it will be there for everyone.

Best,

f


From fperez.net at gmail.com  Thu May 10 02:07:03 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 10 May 2007 00:07:03 -0600
Subject: [IPython-dev] Prefilter reorg ready for trunk
In-Reply-To: <4642550D.5010602@livinglogic.de>
References: <DB04D6A3-3D69-42CF-8D5A-910818AFEE84@comcast.net>
	<46cb515a0705072326j209bd11ah7377990e67d88e65@mail.gmail.com>
	<db6b5ecc0705082212k18a29356k214d3a4983c34da@mail.gmail.com>
	<4641833C.5040008@livinglogic.de>
	<46cb515a0705091254r6d9b49a9w28e576ee19e2bad0@mail.gmail.com>
	<46422FF7.1060800@livinglogic.de>
	<46cb515a0705091410q62e61733k5358b903cb676342@mail.gmail.com>
	<db6b5ecc0705091435o6bdf5218lc55dc9472528e20b@mail.gmail.com>
	<4642550D.5010602@livinglogic.de>
Message-ID: <db6b5ecc0705092307q31e75247lca2bf5789cc1dd19@mail.gmail.com>

On 5/9/07, Walter D?rwald <walter at livinglogic.de> wrote:
> Fernando Perez wrote:
> > On 5/9/07, Ville M. Vainio <vivainio at gmail.com> wrote:
> >> On 5/9/07, Walter D?rwald <walter at livinglogic.de> wrote:
> >>
> >> > Another solution would be to put the HTML as a string into igrid.py
> >> > itself, but then it will no longer work in a standalone browser.
> >>
> >> I think we should just leave it out of the igrid.py file, i.e. put in
> >> fernando's patch, leave the menu button broken and get 0.8.1 released
> >> (with the fixed pyreadline). Finally :-)
> >
> > Walter?  Since this is your baby, I'd like to hear your opinion before
> > taking action.  Keeping both branches open for much longer is a
> > distraction, so we should certainly take action quickly.  But if you
> > feel this is a really important fix, go ahead and do something like
> >
> > html_help = """
> > COPY-PASTE your text here.
> > """
> >
> > for now as a stop-gap measure,
>
> Done (the menu item "Show help in browser" is still broken though).

Thanks.  Next time, please note that we had a branch open for the
release :)  (you applied in trunk, and I'd already cut the release,
uploaded and tagged the tree before noticing... :)

> Nik as a few pending patches for igrid (a few new commands etc.). We'll
> check those in, once 0.8.1 is out the door.

I just did that, though since we had a branch open for that, you could
have gone ahead in trunk no problem.

Cheers,

f


From fperez.net at gmail.com  Thu May 10 02:11:42 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 10 May 2007 00:11:42 -0600
Subject: [IPython-dev] instance docstring vs class docstring
In-Reply-To: <20070508160928.GA2115@clipper.ens.fr>
References: <20070508160928.GA2115@clipper.ens.fr>
Message-ID: <db6b5ecc0705092311w5e2e7072ve7dc4c5c35e98f48@mail.gmail.com>

On 5/8/07, Gael Varoquaux <gael.varoquaux at normalesup.org> wrote:

> Is there a way to avoid this inconvenient ? Do you think modifying
> ipython's "help" function to workaround this would be a good idea ?

help() is part of pydoc, which is, how should I say this politely... a
bit 'messy' :)

So I'm not sure that monkeypatching help() is such a terrific idea.

I'd rather improve '?' so we show *both* instance and class docstrings
when available and different, so that users get all the possible info
about an object (it's likely they both contain useful things).

Cheers,

f


From walter at livinglogic.de  Thu May 10 02:16:09 2007
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Thu, 10 May 2007 08:16:09 +0200
Subject: [IPython-dev] Prefilter reorg ready for trunk
In-Reply-To: <db6b5ecc0705092307q31e75247lca2bf5789cc1dd19@mail.gmail.com>
References: <DB04D6A3-3D69-42CF-8D5A-910818AFEE84@comcast.net>	
	<46cb515a0705072326j209bd11ah7377990e67d88e65@mail.gmail.com>	
	<db6b5ecc0705082212k18a29356k214d3a4983c34da@mail.gmail.com>	
	<4641833C.5040008@livinglogic.de>	
	<46cb515a0705091254r6d9b49a9w28e576ee19e2bad0@mail.gmail.com>	
	<46422FF7.1060800@livinglogic.de>	
	<46cb515a0705091410q62e61733k5358b903cb676342@mail.gmail.com>	
	<db6b5ecc0705091435o6bdf5218lc55dc9472528e20b@mail.gmail.com>	
	<4642550D.5010602@livinglogic.de>
	<db6b5ecc0705092307q31e75247lca2bf5789cc1dd19@mail.gmail.com>
Message-ID: <4642B8A9.80408@livinglogic.de>

Fernando Perez wrote:
> On 5/9/07, Walter D?rwald <walter at livinglogic.de> wrote:
>> Fernando Perez wrote:
>> > On 5/9/07, Ville M. Vainio <vivainio at gmail.com> wrote:
>> >> On 5/9/07, Walter D?rwald <walter at livinglogic.de> wrote:
>> >>
>> >> > Another solution would be to put the HTML as a string into igrid.py
>> >> > itself, but then it will no longer work in a standalone browser.
>> >>
>> >> I think we should just leave it out of the igrid.py file, i.e. put in
>> >> fernando's patch, leave the menu button broken and get 0.8.1 released
>> >> (with the fixed pyreadline). Finally :-)
>> >
>> > Walter?  Since this is your baby, I'd like to hear your opinion before
>> > taking action.  Keeping both branches open for much longer is a
>> > distraction, so we should certainly take action quickly.  But if you
>> > feel this is a really important fix, go ahead and do something like
>> >
>> > html_help = """
>> > COPY-PASTE your text here.
>> > """
>> >
>> > for now as a stop-gap measure,
>>
>> Done (the menu item "Show help in browser" is still broken though).
> 
> Thanks.  Next time, please note that we had a branch open for the
> release :)

Ouch, I totally forgot. Sorry!

> (you applied in trunk, and I'd already cut the release,
> uploaded and tagged the tree before noticing... :)
> 
>> Nik as a few pending patches for igrid (a few new commands etc.). We'll
>> check those in, once 0.8.1 is out the door.
> 
> I just did that, though since we had a branch open for that, you could
> have gone ahead in trunk no problem.

OK.

Servus,
    Walter


From gael.varoquaux at normalesup.org  Thu May 10 02:23:38 2007
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Thu, 10 May 2007 08:23:38 +0200
Subject: [IPython-dev] instance docstring vs class docstring
In-Reply-To: <db6b5ecc0705092311w5e2e7072ve7dc4c5c35e98f48@mail.gmail.com>
References: <20070508160928.GA2115@clipper.ens.fr>
	<db6b5ecc0705092311w5e2e7072ve7dc4c5c35e98f48@mail.gmail.com>
Message-ID: <20070510062338.GC17661@clipper.ens.fr>

On Thu, May 10, 2007 at 12:11:42AM -0600, Fernando Perez wrote:
> On 5/8/07, Gael Varoquaux <gael.varoquaux at normalesup.org> wrote:

> >Is there a way to avoid this inconvenient ? Do you think modifying
> >ipython's "help" function to workaround this would be a good idea ?

> help() is part of pydoc, which is, how should I say this politely... a
> bit 'messy' :)

> So I'm not sure that monkeypatching help() is such a terrific idea.

>From a software engineering I definitely agree with you. From a user
experience things are not as obvious. But this kind of choice obvious
goes to the maintainers of the software :->.

> I'd rather improve '?' so we show *both* instance and class docstrings
> when available and different, so that users get all the possible info
> about an object (it's likely they both contain useful things).

Sure. I must admit I like "?" the way it is. Actually I just checked and I
think this is the way it is behaving, currently.

The reason I was asing this was for the physical constants module. The
objects docstrings are helpful, most helpful actually. The class
docstrings are also quite helpful, though for beginners the mention of
"__str__" and "__repr__" can be a bit confusing.

Ga?l


From fperez.net at gmail.com  Thu May 10 02:37:21 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 10 May 2007 00:37:21 -0600
Subject: [IPython-dev] IPython 0.8.1 and PyReadline 1.4.3 out...
Message-ID: <db6b5ecc0705092337p34c297b6o9dd56655847d40a8@mail.gmail.com>

Hi all,

I just uploaded 0.8.1 and pyreadline 1.4.3 to the usual location:

http://ipython.scipy.org/dist/

The branch should be considered closed (we rarely backport fixes), and
there's a tag as well for reference.

For IPython, this is mostly a bugfix release, but a few new features
did manage to squeeze in:

 * Physical constants module available with the physics profile,
contributed by Gael Varoquaux.

 * Improved 'import completer' by Olivier Lauzanne.

 * New functions in ipapi: defmacro and defalias, to more conveniently
create macros and aliases.

 * A few other small things and bugfixes.  Full details in the ChangeLog:

http://ipython.scipy.org/ChangeLog


I'll leave it to Jorgen to provide us with more details on the
PyReadline work, since I just don't know that codebase at all.


Thanks to all who contributed, and as usual, please let us know of any problems.


Regards,

f


From fperez.net at gmail.com  Thu May 10 03:07:52 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 10 May 2007 01:07:52 -0600
Subject: [IPython-dev] Article about IPython in CiSE
Message-ID: <db6b5ecc0705100007l799c10e6tbf0a2410eb23c2a4@mail.gmail.com>

Hi all,

a small, shameless plug, copied straight from the News page (where I
just added it):

The [http://cise.aip.org/dbt/dbt.jsp?KEY=CSENFA&Volume=9&Issue=3
May/June 2007 issue] of the journal Computing in Science and
Engineering was entirely devoted to Python in scientific computing.
One of the [http://amath.colorado.edu/faculty/fperez/preprints/ipython-cise-final.pdf
featured articles is about IPython].

CiSE is fairly well read in scientific computing circles, so this
should be a big boon for Python in that field.  And what we've heard
from the special issue managing editor (Paul Dubois, the original
Numeric project leader) is that the issue has proven to be one of
CiSE's most popular in a while, with lots of good feedback from their
readers.

Cheers,

f


From erendisaldarion at gmail.com  Thu May 10 03:37:56 2007
From: erendisaldarion at gmail.com (Aldarion)
Date: Thu, 10 May 2007 15:37:56 +0800
Subject: [IPython-dev] [IPython-user] Article about IPython in CiSE
In-Reply-To: <db6b5ecc0705100007l799c10e6tbf0a2410eb23c2a4@mail.gmail.com>
References: <db6b5ecc0705100007l799c10e6tbf0a2410eb23c2a4@mail.gmail.com>
Message-ID: <4642CBD4.4080505@gmail.com>

congratulation, have read every paper of this issue. what's the next 
special issue for Python related Scientific Computing and CFP:)
Fernando Perez wrote:
> Hi all,
>
> a small, shameless plug, copied straight from the News page (where I
> just added it):
>
> The [http://cise.aip.org/dbt/dbt.jsp?KEY=CSENFA&Volume=9&Issue=3
> May/June 2007 issue] of the journal Computing in Science and
> Engineering was entirely devoted to Python in scientific computing.
> One of the [http://amath.colorado.edu/faculty/fperez/preprints/ipython-cise-final.pdf
> featured articles is about IPython].
>
> CiSE is fairly well read in scientific computing circles, so this
> should be a big boon for Python in that field.  And what we've heard
> from the special issue managing editor (Paul Dubois, the original
> Numeric project leader) is that the issue has proven to be one of
> CiSE's most popular in a while, with lots of good feedback from their
> readers.
>
> Cheers,
>
> f
> _______________________________________________
> IPython-user mailing list
> IPython-user at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-user
>
>   



From gakusei at dakotacom.net  Thu May 10 23:13:35 2007
From: gakusei at dakotacom.net (Paul Mueller)
Date: Thu, 10 May 2007 20:13:35 -0700
Subject: [IPython-dev] pycolor: read from STDIN
Message-ID: <20070511031334.GA5121@localhost.localdomain>

Hello,

IPython/PyColorize.py currently doesn't support reading from STDIN when
used from the command line. It would be useful for such things as
coloring the output of svn cat, calling pycolor from scripts (perhaps
not written in python) or programs, grep (sometimes), etc.

Should I submit a patch to add this? If so, I have a question: should
the command-line interface require a "-" in place of the filename to
mean read from STDIN, or should it read from STDIN if "-" or no filename
is given?

I think the later is better, because it is easy to forget the "-":

svn cat -r5 file | pycolor
is easier than
svn cat -r5 file | pycolor -

However, this would change pycolor's current behavior of printing the
help message if no filename is given (I would add a -h/--help option
instead).

I'm also open to rewriting the option parsing to use optparse (or
DPyGetOpt), as per the FIXME comment in main(); I think this would be
preferable to extending the current ad hoc parsing code.

Paul Mueller


From fperez.net at gmail.com  Fri May 11 00:38:17 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 10 May 2007 22:38:17 -0600
Subject: [IPython-dev] Testing trunk in win32?
Message-ID: <db6b5ecc0705102138x230dc4ffj8f892b22fb45d217@mail.gmail.com>

Hi all,

I just committed this

http://projects.scipy.org/ipython/ipython/changeset/2337

to trunk, which fixes a problem on Python 2.3 and potentially
elsewhere (found after a bug reported by SAGE on certain platforms).

But in the process, I cleaned up rlineimpl quite a bit, since the code
seemed to have grown by accretion with some unnecessary repetitions.
On *nix the changes are fine, but I just want to be sure that I didn't
introduce problems for win32 users.  Just in case.

Cheers,

f


From vivainio at gmail.com  Fri May 11 10:53:15 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Fri, 11 May 2007 16:53:15 +0200
Subject: [IPython-dev] pycolor: read from STDIN
In-Reply-To: <20070511031334.GA5121@localhost.localdomain>
References: <20070511031334.GA5121@localhost.localdomain>
Message-ID: <46cb515a0705110753x1ca0a794w149e96d543f9e5fa@mail.gmail.com>

On 5/11/07, Paul Mueller <gakusei at dakotacom.net> wrote:

> IPython/PyColorize.py currently doesn't support reading from STDIN when
> used from the command line. It would be useful for such things as
> coloring the output of svn cat, calling pycolor from scripts (perhaps
> not written in python) or programs, grep (sometimes), etc.
>
> Should I submit a patch to add this? If so, I have a question: should

Yes.

> the command-line interface require a "-" in place of the filename to
> mean read from STDIN, or should it read from STDIN if "-" or no filename
> is given?
>
> I think the later is better, because it is easy to forget the "-":

Yeah, and it's pretty much the standard on unix.

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From vivainio at gmail.com  Fri May 11 12:46:04 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Fri, 11 May 2007 18:46:04 +0200
Subject: [IPython-dev] Testing trunk in win32?
In-Reply-To: <db6b5ecc0705102138x230dc4ffj8f892b22fb45d217@mail.gmail.com>
References: <db6b5ecc0705102138x230dc4ffj8f892b22fb45d217@mail.gmail.com>
Message-ID: <46cb515a0705110946w4033f565m3fbb675d683c173@mail.gmail.com>

On 5/11/07, Fernando Perez <fperez.net at gmail.com> wrote:

> But in the process, I cleaned up rlineimpl quite a bit, since the code
> seemed to have grown by accretion with some unnecessary repetitions.
> On *nix the changes are fine, but I just want to be sure that I didn't
> introduce problems for win32 users.  Just in case.

It's ok, both with and w/o pyreadline.

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From gakusei at dakotacom.net  Sat May 12 19:49:08 2007
From: gakusei at dakotacom.net (Paul Mueller)
Date: Sat, 12 May 2007 16:49:08 -0700
Subject: [IPython-dev] pycolor: read from STDIN
In-Reply-To: <46cb515a0705110753x1ca0a794w149e96d543f9e5fa@mail.gmail.com>
References: <20070511031334.GA5121@localhost.localdomain>
	<46cb515a0705110753x1ca0a794w149e96d543f9e5fa@mail.gmail.com>
Message-ID: <20070512234908.GA5111@localhost.localdomain>

Hi,

Here is the patch to pycolor (& it's man page) to allow it to read from
stdin. I've redone the cmdline parsing code to use optparse, which is
less messy & brittle than the old way would have been if I had extended
it.

I've split the modifications into two patches, in order to facilitate
logically separate commits if you want to do so:

pycolor_read_from_stdin_patch1.diff:
    has the current functionality but uses optparse
pycolor_read_from_stdin_patch2.diff:
    adds STDIN support; apply after applying
    pycolor_read_from_stdin_patch1.diff

Thanks,
Paul Mueller
-------------- next part --------------
Index: IPython/PyColorize.py
===================================================================
--- IPython/PyColorize.py	(revision 2337)
+++ IPython/PyColorize.py	(working copy)
@@ -38,6 +38,7 @@
 import cStringIO
 import keyword
 import os
+import optparse
 import string
 import sys
 import token
@@ -242,42 +243,38 @@
         # send text
         owrite('%s%s%s' % (color,toktext,colors.normal))
             
-def main():
-    """Colorize a python file using ANSI color escapes and print to stdout.
+def main(argv=None):
+    """Run as a command-line script: colorize a python file using ANSI color
+    escapes and print to stdout.
 
-    Usage:
-      %s [-s scheme] filename
+    Inputs:
 
-    Options:
+      - argv(None): a list of strings like sys.argv[1:] giving the command-line
+        arguments. If None, use sys.argv[1:].
+    """
 
-      -s scheme: give the color scheme to use. Currently only 'Linux'
-      (default) and 'LightBG' and 'NoColor' are implemented (give without
-      quotes).  """  
+    usage_msg = """%prog [options] filename
 
-    def usage():
-        print >> sys.stderr, main.__doc__ % sys.argv[0]
-        sys.exit(1)
-        
-    # FIXME: rewrite this to at least use getopt
-    try:
-        if sys.argv[1] == '-s':
-            scheme_name = sys.argv[2]
-            del sys.argv[1:3]
-        else:
-            scheme_name = _scheme_default
-        
-    except:
-        usage()
+Colorize a python file using ANSI color escapes and print to stdout."""
 
-    try:
-        fname = sys.argv[1]
-    except:
-        usage()
-        
+    parser = optparse.OptionParser(usage=usage_msg)
+    newopt = parser.add_option
+    newopt('-s','--scheme',metavar='NAME',dest='scheme_name',action='store',
+           choices=['Linux','LightBG','NoColor'],default=_scheme_default,
+           help="give the color scheme to use. Currently only 'Linux'\
+ (default) and 'LightBG' and 'NoColor' are implemented (give without\
+ quotes)")
+
+    opts,args = parser.parse_args(argv)
+
+    if len(args) != 1:
+        parser.error("you must give one filename.")
+
     # write colorized version to stdout
+    fname = args[0]
     parser = Parser()
     try:
-        parser.format(file(fname).read(),scheme = scheme_name)
+        parser.format(file(fname).read(),scheme=opts.scheme_name)
     except IOError,msg:
         # if user reads through a pager and quits, don't print traceback
         if msg.args != (32,'Broken pipe'):
Index: doc/pycolor.1
===================================================================
--- doc/pycolor.1	(revision 2337)
+++ doc/pycolor.1	(working copy)
@@ -2,7 +2,7 @@
 .\" First parameter, NAME, should be all caps
 .\" Second parameter, SECTION, should be 1-8, maybe w/ subsection
 .\" other parameters are allowed: see man(7), man(1)
-.TH PYCOLOR 1 "March 21, 2003"
+.TH PYCOLOR 1 "May 12, 2007"
 .\" Please adjust this date whenever revising the manpage.
 .\"
 .\" Some roff macros, for reference:
@@ -24,7 +24,10 @@
 Prints a colorized version of the input file to standard out.
 .SH OPTIONS
 .TP
-.B \-s <scheme>
+.B \-h, \-\-help
+Output a brief help message.
+.TP
+.B \-s, \-\-scheme <scheme>
 Give the color scheme to use.  Currently only Linux (default),
 LightBG, and NOColor are implemented.
 .SH AUTHOR
-------------- next part --------------
Index: IPython/PyColorize.py
===================================================================
--- IPython/PyColorize.py
+++ IPython/PyColorize.py  (working copy)
@@ -244,8 +244,8 @@
         owrite('%s%s%s' % (color,toktext,colors.normal))
             
 def main(argv=None):
-    """Run as a command-line script: colorize a python file using ANSI color
-    escapes and print to stdout.
+    """Run as a command-line script: colorize a python file or stdin using ANSI
+    color escapes and print to stdout.

     Inputs:

@@ -253,9 +253,10 @@
         arguments. If None, use sys.argv[1:].
     """

-    usage_msg = """%prog [options] filename
+    usage_msg = """%prog [options] [filename]

-Colorize a python file using ANSI color escapes and print to stdout."""
+Colorize a python file or stdin using ANSI color escapes and print to stdout.
+If no filename is given, or if filename is -, read standard input."""

     parser = optparse.OptionParser(usage=usage_msg)
     newopt = parser.add_option
@@ -267,18 +268,34 @@

     opts,args = parser.parse_args(argv)

-    if len(args) != 1:
-        parser.error("you must give one filename.")
+    if len(args) > 1:
+        parser.error("you must give at most one filename.")
+
+    if len(args) == 0:
+        fname = '-' # no filename given; setup to read from stdin
+    else:
+        fname = args[0]
+
+    if fname == '-':
+        stream = sys.stdin
+    else:
+        stream = file(fname)

-    # write colorized version to stdout
-    fname = args[0]
     parser = Parser()
+
+    # we need nested try blocks because pre-2.5 python doesn't support unified
+    # try-except-finally
     try:
-        parser.format(file(fname).read(),scheme=opts.scheme_name)
-    except IOError,msg:
-        # if user reads through a pager and quits, don't print traceback
-        if msg.args != (32,'Broken pipe'):
-            raise
+        try:
+            # write colorized version to stdout
+            parser.format(stream.read(),scheme=opts.scheme_name)
+        except IOError,msg:
+            # if user reads through a pager and quits, don't print traceback
+            if msg.args != (32,'Broken pipe'):
+                raise
+    finally:
+        if stream is not sys.stdin:
+            stream.close() # in case a non-handled exception happened above

 if __name__ == "__main__":
     main()
Index: doc/pycolor.1
===================================================================
--- doc/pycolor.1
+++ doc/pycolor.1 (working copy)
@@ -16,12 +16,14 @@
 .\" .sp <n>    insert n+1 empty lines
 .\" for manpage-specific macros, see man(7)
 .SH NAME
-pycolor \- Colorize a python file using ANSI and print to stdout.
+pycolor \- Colorize a python file or stdin using ANSI and print to stdout.
 .SH SYNOPSIS
 .B pycolor
-.RI [ options ] " file"
+.RI [ options ]
+.RI [ file ]
 .SH DESCRIPTION
-Prints a colorized version of the input file to standard out.
+Prints a colorized version of the input file (or standard input if no file is
+given, or the file name - is given) to standard out.
 .SH OPTIONS
 .TP
 .B \-h, \-\-help

From ondrej.marsalek at matfyz.cz  Sun May 13 08:00:05 2007
From: ondrej.marsalek at matfyz.cz (Ondrej Marsalek)
Date: Sun, 13 May 2007 14:00:05 +0200
Subject: [IPython-dev] failed installation of ipython1
Message-ID: <97b6a4330705130500j1be0b07du66fcf1c3eee74823@mail.gmail.com>

hello everybody,

at first i would like to thank all the people who contribute to
ipython, especially the new ipython1 features. a few days ago a saw
the msri video and i am really excited about the parallelization
features and the potential in all this.

now to my problem: i tried to install ipython1 from svn on an ubuntu
feisty fawn box (i can provide more details if needed) and it seems it
was not successful. below i provide the end of the installation
transcript and the failed "trial ipython1" bellow.

based "IndentationError" i assume it is sth trivial, but i do not have
any experience with python packages management, so i can't tell for
sure.

thanks for any help,
ondrej marsalek


-------------------------------------------------------------------------------


the final part of the installation
-------------------------------------------
byte-compiling build/bdist.linux-i686/egg/ipython1/core1/interpreterinterface.py
to interpreterinterface.pyc
Sorry: IndentationError: ('expected an indented block',
('build/bdist.linux-i686/egg/ipython1/core1/interpreterinterface.py',
8, 7, '    def execute(self, lines):\n'))
byte-compiling build/bdist.linux-i686/egg/ipython1/core1/some_magics.py
to some_magics.pyc
byte-compiling build/bdist.linux-i686/egg/ipython1/core1/output_trap.py
to output_trap.pyc
byte-compiling build/bdist.linux-i686/egg/ipython1/core1/test/testTEMPLATE.py
to testTEMPLATE.pyc
byte-compiling build/bdist.linux-i686/egg/ipython1/core1/test/tcommon.py
to tcommon.pyc
byte-compiling build/bdist.linux-i686/egg/ipython1/core1/test/__init__.py
to __init__.pyc
byte-compiling build/bdist.linux-i686/egg/ipython1/core1/test/test_all_doctests.py
to test_all_doctests.pyc
byte-compiling build/bdist.linux-i686/egg/ipython1/bonjour/twistbonjour.py
to twistbonjour.pyc
byte-compiling build/bdist.linux-i686/egg/ipython1/bonjour/__init__.py
to __init__.pyc
creating build/bdist.linux-i686/egg/EGG-INFO
copying ipython1.egg-info/PKG-INFO -> build/bdist.linux-i686/egg/EGG-INFO
copying ipython1.egg-info/SOURCES.txt -> build/bdist.linux-i686/egg/EGG-INFO
copying ipython1.egg-info/dependency_links.txt ->
build/bdist.linux-i686/egg/EGG-INFO
copying ipython1.egg-info/entry_points.txt ->
build/bdist.linux-i686/egg/EGG-INFO
copying ipython1.egg-info/not-zip-safe -> build/bdist.linux-i686/egg/EGG-INFO
copying ipython1.egg-info/top_level.txt -> build/bdist.linux-i686/egg/EGG-INFO
creating dist
creating 'dist/ipython1-0.9alpha2-py2.5.egg' and adding
'build/bdist.linux-i686/egg' to it
removing 'build/bdist.linux-i686/egg' (and everything under it)
Processing ipython1-0.9alpha2-py2.5.egg
creating /usr/lib/python2.5/site-packages/ipython1-0.9alpha2-py2.5.egg
Extracting ipython1-0.9alpha2-py2.5.egg to /usr/lib/python2.5/site-packages
Sorry: IndentationError: ('expected an indented block',
('/usr/lib/python2.5/site-packages/ipython1-0.9alpha2-py2.5.egg/ipython1/kernel/taskhttp.py',
136, 0, 'class HTTPTaskRegisterClient(HTTPTaskBaseMethod):\n'))
Sorry: IndentationError: ('expected an indented block',
('/usr/lib/python2.5/site-packages/ipython1-0.9alpha2-py2.5.egg/ipython1/core1/interpreterinterface.py',
8, 7, '    def execute(self, lines):\n'))
Adding ipython1 0.9alpha2 to easy-install.pth file
Installing ipcluster script to /usr/bin
Installing ipcontroller script to /usr/bin
Installing ipengine script to /usr/bin

Installed /usr/lib/python2.5/site-packages/ipython1-0.9alpha2-py2.5.egg
Processing dependencies for ipython1==0.9alpha2


parts of "trial ipython1"
--------------------------------
.
.
.
WARNING:
Error in Arguments: "Illegal option '--noterm_title'"
.
.
.
ipython1.test.test_newserialized
  SerializedTestCase
    testNDArraySerialized ...                                              [OK]
    testPickleSerialized ...                                               [OK]
    testSerializedInterfaces ...                                           [OK]
                                       [ERROR]
ipython1.test.test_shell
  BasicShellTest
    testCommand ...                                                        [OK]
    testExecute ...                                                        [OK]
    testPutGet ...                                                         [OK]
    testUpdate ...                                                         [OK]
                                                     [ERROR]

===============================================================================
[ERROR]: ipython1.test.test_pendingdeferred

Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/twisted/trial/runner.py",
line 555, in loadPackage
    module = modinfo.load()
  File "/usr/lib/python2.5/site-packages/twisted/python/modules.py",
line 386, in load
    return self.pathEntry.pythonPath.moduleLoader(self.name)
  File "/usr/lib/python2.5/site-packages/twisted/python/modules.py",
line 621, in moduleLoader
    return self._moduleLoader(modname)
  File "/usr/lib/python2.5/site-packages/twisted/python/reflect.py",
line 357, in namedAny
    topLevelPackage = __import__(trialname)
  File "/usr/lib/python2.5/site-packages/ipython1-0.9alpha2-py2.5.egg/ipython1/test/test_pendingdeferred.py",
line 20, in <module>
    import tcommon
  File "/usr/lib/python2.5/site-packages/ipython1-0.9alpha2-py2.5.egg/ipython1/test/tcommon.py",
line 30, in <module>
    from ipython1.test.ipdoctest import IPDocTestLoader,makeTestSuite
  File "/usr/lib/python2.5/site-packages/ipython1-0.9alpha2-py2.5.egg/ipython1/test/ipdoctest.py",
line 78, in <module>
    ipython = IPython.Shell.IPShell(['--classic','--noterm_title']).IP
  File "/usr/lib/python2.5/site-packages/IPython/Shell.py", line 56, in __init__
    debug=debug,shell_class=shell_class)
  File "/usr/lib/python2.5/site-packages/IPython/ipmaker.py", line
297, in make_IPython
    sys.exit(1)
exceptions.SystemExit: 1
===============================================================================
[ERROR]: ipython1.test.test_tools_utils

Traceback (most recent call last):
  File "/usr/lib/python2.5/site-packages/twisted/trial/runner.py",
line 555, in loadPackage
    module = modinfo.load()
  File "/usr/lib/python2.5/site-packages/twisted/python/modules.py",
line 386, in load
    return self.pathEntry.pythonPath.moduleLoader(self.name)
  File "/usr/lib/python2.5/site-packages/twisted/python/modules.py",
line 621, in moduleLoader
    return self._moduleLoader(modname)
  File "/usr/lib/python2.5/site-packages/twisted/python/reflect.py",
line 357, in namedAny
    topLevelPackage = __import__(trialname)
  File "/usr/lib/python2.5/site-packages/ipython1-0.9alpha2-py2.5.egg/ipython1/test/test_tools_utils.py",
line 6, in <module>
    import tcommon
  File "/usr/lib/python2.5/site-packages/ipython1-0.9alpha2-py2.5.egg/ipython1/test/tcommon.py",
line 30, in <module>
    from ipython1.test.ipdoctest import IPDocTestLoader,makeTestSuite
  File "/usr/lib/python2.5/site-packages/ipython1-0.9alpha2-py2.5.egg/ipython1/test/ipdoctest.py",
line 78, in <module>
    ipython = IPython.Shell.IPShell(['--classic','--noterm_title']).IP
  File "/usr/lib/python2.5/site-packages/IPython/Shell.py", line 56, in __init__
    debug=debug,shell_class=shell_class)
  File "/usr/lib/python2.5/site-packages/IPython/ipmaker.py", line
297, in make_IPython
    sys.exit(1)
exceptions.SystemExit: 1
-------------------------------------------------------------------------------
Ran 93 tests in 5.908s

FAILED (errors=2, successes=93)


From fperez.net at gmail.com  Sun May 13 19:45:10 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 13 May 2007 17:45:10 -0600
Subject: [IPython-dev] A question on the win32 installer
Message-ID: <db6b5ecc0705131645x593d69a8gdfa1c1b59662a9c0@mail.gmail.com>

Hi all,

I'm a bit confused by what we have on the post-install script front.
We have the following:


tlon[ipython]> pwd
/home/fperez/ipython/svn/ipython/trunk
tlon[ipython]> ls win32_manual_post_install.py
win32_manual_post_install.py*
tlon[ipython]> ls scripts/ipython_win_post_install.py
scripts/ipython_win_post_install.py*

Recent patches to the installer went into the one under scripts/, and
the 'release' script has the following stanza:

./setup.py bdist_wininst --install-script=ipython_win_post_install.py

My questions are:

1. Is that stanza really correct?  It doesn't use a path, so I don't
know if it will really be picked up as it should at runtime.  But
maybe it will because it's listed in the scripts/ part of setup.py, I
dunno.

2. Is the file win32_manual_post_install.py really needed?  I realize
one seems to be for manual installs, but I wonder if we can't merge
them into a single script.  I worry about the duplication and chances
for them diverging, the need for duplicate maintenance as one is
changed, etc.

What do our win32 gurus say?

Cheers,

f


From vivainio at gmail.com  Mon May 14 02:33:15 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Mon, 14 May 2007 08:33:15 +0200
Subject: [IPython-dev] A question on the win32 installer
In-Reply-To: <db6b5ecc0705131645x593d69a8gdfa1c1b59662a9c0@mail.gmail.com>
References: <db6b5ecc0705131645x593d69a8gdfa1c1b59662a9c0@mail.gmail.com>
Message-ID: <46cb515a0705132333w24c5f662i77ccf7c3a2a7aa5a@mail.gmail.com>

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

> Recent patches to the installer went into the one under scripts/, and
> the 'release' script has the following stanza:
>
> ./setup.py bdist_wininst --install-script=ipython_win_post_install.py
>
> My questions are:
>
> 1. Is that stanza really correct?  It doesn't use a path, so I don't
> know if it will really be picked up as it should at runtime.  But
> maybe it will because it's listed in the scripts/ part of setup.py, I
> dunno.

Yes, it is correct and picked up correctly on runtime.

> 2. Is the file win32_manual_post_install.py really needed?  I realize
> one seems to be for manual installs, but I wonder if we can't merge
> them into a single script.  I worry about the duplication and chances
> for them diverging, the need for duplicate maintenance as one is
> changed, etc.

Yeah, we could merge them into one script. In fact, I think we should
only have one script that the installer launches, and most of the work
would be performed by a normal functions, e.g.
IPython.installer.shortcuts - which, when launched outside the windows
installer, would of course require pywin32 exension.

I don't see too much rush with this, though. Does anyone even use the
manual install script?


-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From fperez.net at gmail.com  Mon May 14 11:08:07 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 14 May 2007 09:08:07 -0600
Subject: [IPython-dev] A question on the win32 installer
In-Reply-To: <46cb515a0705132333w24c5f662i77ccf7c3a2a7aa5a@mail.gmail.com>
References: <db6b5ecc0705131645x593d69a8gdfa1c1b59662a9c0@mail.gmail.com>
	<46cb515a0705132333w24c5f662i77ccf7c3a2a7aa5a@mail.gmail.com>
Message-ID: <db6b5ecc0705140808h64544354j3f39a2649978ecd5@mail.gmail.com>

On 5/14/07, Ville M. Vainio <vivainio at gmail.com> wrote:

> Yeah, we could merge them into one script. In fact, I think we should
> only have one script that the installer launches, and most of the work
> would be performed by a normal functions, e.g.
> IPython.installer.shortcuts - which, when launched outside the windows
> installer, would of course require pywin32 exension.

Agreed.

> I don't see too much rush with this, though. Does anyone even use the
> manual install script?

No big rush, no.  I just wanted to clarify what's going on, mostly for
my own sake.  I suspect the manual installer isn't very widely used,
but I'm just guessing.

Thanks for the feedback.

Cheers,

f


From fperez.net at gmail.com  Mon May 14 13:10:05 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 14 May 2007 11:10:05 -0600
Subject: [IPython-dev] failed installation of ipython1
In-Reply-To: <97b6a4330705130500j1be0b07du66fcf1c3eee74823@mail.gmail.com>
References: <97b6a4330705130500j1be0b07du66fcf1c3eee74823@mail.gmail.com>
Message-ID: <db6b5ecc0705141010w1152a3a2x35ce6806a34c542d@mail.gmail.com>

Hi Ondrej,

On 5/13/07, Ondrej Marsalek <ondrej.marsalek at matfyz.cz> wrote:
> hello everybody,
>
> at first i would like to thank all the people who contribute to
> ipython, especially the new ipython1 features. a few days ago a saw
> the msri video and i am really excited about the parallelization
> features and the potential in all this.
>
> now to my problem: i tried to install ipython1 from svn on an ubuntu
> feisty fawn box (i can provide more details if needed) and it seems it
> was not successful. below i provide the end of the installation
> transcript and the failed "trial ipython1" bellow.

Sorry about that.  I think most of us are running straight from the
dev directory, so we hadn't really noticed this.  I fixed a few small
problems from your traceback, let us know how it goes.


> WARNING:
> Error in Arguments: "Illegal option '--noterm_title'"

Your main ipython is probably not current enough, I'm afraid.  You'll
need the most recent release, 0.8.1, for all of this to work smoothly.

Regards,

f


From ondrej.marsalek at matfyz.cz  Mon May 14 13:46:58 2007
From: ondrej.marsalek at matfyz.cz (Ondrej Marsalek)
Date: Mon, 14 May 2007 19:46:58 +0200
Subject: [IPython-dev] failed installation of ipython1
In-Reply-To: <db6b5ecc0705141010w1152a3a2x35ce6806a34c542d@mail.gmail.com>
References: <97b6a4330705130500j1be0b07du66fcf1c3eee74823@mail.gmail.com>
	<db6b5ecc0705141010w1152a3a2x35ce6806a34c542d@mail.gmail.com>
Message-ID: <97b6a4330705141046xf33800bta328867e63bc9818@mail.gmail.com>

> Sorry about that.  I think most of us are running straight from the
> dev directory, so we hadn't really noticed this.  I fixed a few small
> problems from your traceback, let us know how it goes.

no problem. now the install seems fine, nothing suspicious. trial,
however, raises an exception at the very begining. see listing below.

> Your main ipython is probably not current enough, I'm afraid.  You'll
> need the most recent release, 0.8.1, for all of this to work smoothly.

true. feisty fawn has 0.7.3 in the repos. i installed from svn, so now
i have 0.8.2.svn.r2333.

regards,
ondrej


traceback of the problem:
(there really is not a single txt file in that directory)

andy at kevf119:~$ trial ipython1
Traceback (most recent call last):
  File "/usr/bin/trial", line 24, in <module>
    run()
  File "/usr/lib/python2.5/site-packages/twisted/scripts/trial.py",
line 341, in run
    suite = _getSuite(config)
  File "/usr/lib/python2.5/site-packages/twisted/scripts/trial.py",
line 301, in _getSuite
    return loader.loadByNames(config['tests'], recurse)
  File "/usr/lib/python2.5/site-packages/twisted/trial/runner.py",
line 635, in loadByNames
    for thing in sets.Set(things)]
  File "/usr/lib/python2.5/site-packages/twisted/trial/runner.py",
line 592, in loadAnything
    return self.loadPackage(thing, recurse)
  File "/usr/lib/python2.5/site-packages/twisted/trial/runner.py",
line 559, in loadPackage
    thingToAdd = self.loadModule(module)
  File "/usr/lib/python2.5/site-packages/twisted/trial/runner.py",
line 471, in loadModule
    return module.testSuite()
  File "/usr/lib/python2.5/site-packages/ipython1-0.9alpha2-py2.5.egg/ipython1/test/test_tools_utils.py",
line 34, in <lambda>
    testSuite = lambda : makeTestSuite(__name__,dt_files,dt_modules)
  File "/usr/lib/python2.5/site-packages/ipython1-0.9alpha2-py2.5.egg/ipython1/test/ipdoctest.py",
line 535, in makeTestSuite
    return IPDocTestLoader(dt_files,dt_modules).loadTestsFromModule(mod)
  File "/usr/lib/python2.5/site-packages/ipython1-0.9alpha2-py2.5.egg/ipython1/test/ipdoctest.py",
line 498, in loadTestsFromModule
    suite.addTest(doctest.DocFileSuite(fname))
  File "/usr/lib/python2.5/doctest.py", line 2381, in DocFileSuite
    suite.addTest(DocFileTest(path, **kw))
  File "/usr/lib/python2.5/doctest.py", line 2300, in DocFileTest
    doc, path = _load_testfile(path, package, module_relative)
  File "/usr/lib/python2.5/doctest.py", line 213, in _load_testfile
    return open(filename).read(), filename
IOError: [Errno 2] No such file or directory:
'/usr/lib/python2.5/site-packages/ipython1-0.9alpha2-py2.5.egg/ipython1/test/tst_tools_utils_doctest.txt'


From ondrej.marsalek at matfyz.cz  Tue May 15 06:54:02 2007
From: ondrej.marsalek at matfyz.cz (Ondrej Marsalek)
Date: Tue, 15 May 2007 12:54:02 +0200
Subject: [IPython-dev] magic and imports on engines
Message-ID: <97b6a4330705150354o5c3972b8kdf6152026c5493fc@mail.gmail.com>

hi,

i hope this is not too inappropriate on a dev list but i was not able
to find the info elsewhere.

is there a way to run magic commands on the remote engines? they don't
seem to recognize the magic % syntax and even the "full" syntax, eg.
px _ip.magic('pwd'), raises a NameError.

the other thing - i changed to a directory (using os.chdir) where i
have a package directory and tried to import this on the engines (it
works in a normal ipython shell). this raises an ImportError.

any help greatly appreciated,
ondrej marsalek


From ellisonbg.net at gmail.com  Tue May 15 12:59:40 2007
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Tue, 15 May 2007 10:59:40 -0600
Subject: [IPython-dev] magic and imports on engines
In-Reply-To: <97b6a4330705150354o5c3972b8kdf6152026c5493fc@mail.gmail.com>
References: <97b6a4330705150354o5c3972b8kdf6152026c5493fc@mail.gmail.com>
Message-ID: <6ce0ac130705150959h5b0e753oed68d8cd641577e3@mail.gmail.com>

So as of today, the engines run a plain vanilla python interpreter.
Thus, nothing that you can do with IPython will work on the engines.
But..., we are currently in the process of porting and refactoring the
entire IPython interpreter to IPython1 and the engines.  In fact, this
is why the parallel stuff is called IPython1 - eventually it _will be_
the 1.0 release of IPython itself.

But, because of how IPython grew up, it is welded to the terminal and
its parts are not factored in a way that makes it maintainable and
easily extensible.  This is also partially why IPython has
traditionally not had very good test coverage.  All this is changing
for the better in IPython1, but it is slow work.

One of our goals in this transition is to provide continuing support
for the 0.8 versions of IPython and allow the stuff in IPython1 to
coexist with that so that it can be used for parallel distributed
computing.  Please let us know if you have any other problems.  I will
be fixing the problems you ran into running trial ipython1 today.

Cheers,

Brian

On 5/15/07, Ondrej Marsalek <ondrej.marsalek at matfyz.cz> wrote:
> hi,
>
> i hope this is not too inappropriate on a dev list but i was not able
> to find the info elsewhere.
>
> is there a way to run magic commands on the remote engines? they don't
> seem to recognize the magic % syntax and even the "full" syntax, eg.
> px _ip.magic('pwd'), raises a NameError.
>
> the other thing - i changed to a directory (using os.chdir) where i
> have a package directory and tried to import this on the engines (it
> works in a normal ipython shell). this raises an ImportError.
>
> any help greatly appreciated,
> ondrej marsalek
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>


From vivainio at gmail.com  Tue May 15 13:01:40 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 15 May 2007 19:01:40 +0200
Subject: [IPython-dev] Macro system overhaul done, testing needed.
Message-ID: <46cb515a0705151001r2060c9adraa815be6165577a0@mail.gmail.com>

Macros are no longer "special" in svn version of trunk.

Instead, they inherit from ipapi.IPyAutocall,  instances of which get
autocalled regardless of autocall mode setting.

See

http://projects.scipy.org/ipython/ipython/changeset/2349
http://projects.scipy.org/ipython/ipython/changeset/2350

for implementation.

There is still some fun to be had, such as adding the macro arguments.

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From ondrej.marsalek at matfyz.cz  Tue May 15 13:18:06 2007
From: ondrej.marsalek at matfyz.cz (Ondrej Marsalek)
Date: Tue, 15 May 2007 19:18:06 +0200
Subject: [IPython-dev] magic and imports on engines
In-Reply-To: <6ce0ac130705150959h5b0e753oed68d8cd641577e3@mail.gmail.com>
References: <97b6a4330705150354o5c3972b8kdf6152026c5493fc@mail.gmail.com>
	<6ce0ac130705150959h5b0e753oed68d8cd641577e3@mail.gmail.com>
Message-ID: <97b6a4330705151018v505807d4nf94028671b955569@mail.gmail.com>

On 15/05/07, Brian Granger <ellisonbg.net at gmail.com> wrote:
> So as of today, the engines run a plain vanilla python interpreter.
> Thus, nothing that you can do with IPython will work on the engines.

thanks for the explanation, looking forward to the 1.0 release :-)

> computing.  Please let us know if you have any other problems.  I will
> be fixing the problems you ran into running trial ipython1 today.

well, i still have this problem with the import of a module or package
in the current directory. it works in ipython and vanilla python. it
does not work on the engines, as i said before. i would like to use my
own extensions, so this is quite important.


ondrej


From vivainio at gmail.com  Tue May 15 13:38:17 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 15 May 2007 19:38:17 +0200
Subject: [IPython-dev] Macro system overhaul done, testing needed.
In-Reply-To: <46cb515a0705151001r2060c9adraa815be6165577a0@mail.gmail.com>
References: <46cb515a0705151001r2060c9adraa815be6165577a0@mail.gmail.com>
Message-ID: <46cb515a0705151038v741ed54bm418e9eeecca042aa@mail.gmail.com>

On 5/15/07, Ville M. Vainio <vivainio at gmail.com> wrote:

> There is still some fun to be had, such as adding the macro arguments.

Not anymore:

http://ipython.scipy.org/moin/Cookbook/MacroArguments

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From Glen.Mabey at swri.org  Tue May 15 14:12:08 2007
From: Glen.Mabey at swri.org (Glen W. Mabey)
Date: Tue, 15 May 2007 13:12:08 -0500
Subject: [IPython-dev] magic and imports on engines
In-Reply-To: <97b6a4330705151018v505807d4nf94028671b955569@mail.gmail.com>
References: <97b6a4330705150354o5c3972b8kdf6152026c5493fc@mail.gmail.com>
	<6ce0ac130705150959h5b0e753oed68d8cd641577e3@mail.gmail.com>
	<97b6a4330705151018v505807d4nf94028671b955569@mail.gmail.com>
Message-ID: <20070515181208.GK20352@bams.ccf.swri.edu>

On Tue, May 15, 2007 at 07:18:06PM +0200, Ondrej Marsalek wrote:
> well, i still have this problem with the import of a module or package
> in the current directory. it works in ipython and vanilla python. it
> does not work on the engines, as i said before. i would like to use my
> own extensions, so this is quite important.

Here's what I do to import modules from the current directory into
ipengines:

    ipy1_remote_controller.executeAll( 'import site' )
    ipy1_remote_controller.executeAll( 'site.addsitedir( ' + `os.getcwd()` + ' )' )
    ipy1_remote_controller.executeAll( 'import themodule; reload( themodule )' )

The reload is important so that if you modify the code, the most recent
version gets used.

Glen



From vivainio at gmail.com  Tue May 15 14:14:40 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 15 May 2007 20:14:40 +0200
Subject: [IPython-dev] Using IPyAutocall + 'command namespace' to get rid of
	aliases and magics
Message-ID: <46cb515a0705151114p866fb57r989caeb1d8b8a76d@mail.gmail.com>

Here's something I've though of for a while, but never got around to
implementing:

- Create a 'command namespace', a normal namespace (dict) that is used
for name lookup only when looking up commands, i.e. typically when we
are at start of the line.

- Put all aliases, direct system commands and magics there:

{
'cd' : <MagicCd instance at blah blah>,
'cp' : <SysCommandFormarder at 777>,
'mv': <SysCommandFormarder at 777>,
'd' : <IpyAlias('ls -F')>, ...
}

- Invoke them "kind-of" normally via autocall mechanism. They have
access to full input line, enabling 'sys command forwarder' and
magics.

The 'command namespace' would not be shows via %whos, and it's not
available for normal variable use. However, it's available in
beginning-of-line completer.

All of this isn't a lot of code, but would lead to simpler, less
'special cased' and easier to understand IPython codebase without
sacrificing existing usability.

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From fperez.net at gmail.com  Tue May 15 14:23:47 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 15 May 2007 12:23:47 -0600
Subject: [IPython-dev] Using IPyAutocall + 'command namespace' to get
	rid of aliases and magics
In-Reply-To: <46cb515a0705151114p866fb57r989caeb1d8b8a76d@mail.gmail.com>
References: <46cb515a0705151114p866fb57r989caeb1d8b8a76d@mail.gmail.com>
Message-ID: <db6b5ecc0705151123p6c7a0824mc83354e94646413c@mail.gmail.com>

On 5/15/07, Ville M. Vainio <vivainio at gmail.com> wrote:
> Here's something I've though of for a while, but never got around to
> implementing:

just a quick note, I can't really reply right now.  I'm leaving for a
trip in a minute and will be mostly off-line until next week.   I'll
try to catch up with feedback when I return.

Cheers,

f


From danmil at comcast.net  Tue May 15 15:55:41 2007
From: danmil at comcast.net (Dan Milstein)
Date: Tue, 15 May 2007 15:55:41 -0400
Subject: [IPython-dev] Trying Again with Prefilter ;-)
Message-ID: <3C0EFE6B-4F2C-467E-8635-50380957EAC5@comcast.net>

Okay, so have we pushed 0.8.1 out there?  Can I merge in my changes  
to trunk?

-D


From vivainio at gmail.com  Tue May 15 16:53:51 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 15 May 2007 22:53:51 +0200
Subject: [IPython-dev] Trying Again with Prefilter ;-)
In-Reply-To: <3C0EFE6B-4F2C-467E-8635-50380957EAC5@comcast.net>
References: <3C0EFE6B-4F2C-467E-8635-50380957EAC5@comcast.net>
Message-ID: <46cb515a0705151353l3a202e60pf8b252c693e5ce94@mail.gmail.com>

On 5/15/07, Dan Milstein <danmil at comcast.net> wrote:

> Okay, so have we pushed 0.8.1 out there?  Can I merge in my changes
> to trunk?

YES. :-)

I'm been shuffling some things around today, esp. autocall, so be careful...

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From danmil at comcast.net  Wed May 16 09:25:53 2007
From: danmil at comcast.net (Dan Milstein)
Date: Wed, 16 May 2007 09:25:53 -0400
Subject: [IPython-dev] Prefilter Reorg Committed
Message-ID: <2B5EDCAE-9C6C-481B-A51F-514780937B80@comcast.net>

...finally ;-)

Okay, I just went ahead and committed it to the trunk (r. 2354).

A few notes:

Hey Look, It's a Suite of Tests
===============================

The most useful thing I've got is, IMHO, two fairly extensive suites  
of tests, both in the tests/ directory:

test_prefilter.py
test_handlers.py

Both are, I think, pretty solidly documented.  To run them, you do  
like so from command line:

 > python test_prefilter.py

or

 > python test_handlers.py

(with the relevant version of IPython in your PYTHONPATH).  Notice  
that that is 'python', *not* 'ipython'.

If we can keep those tests up to date, we can go after fairly  
ambitious reorganizations of the input-transformation code with  
decent confidence that things Will Keep Working.

My sincere hope is that it will be easy to add new tests.  If folks  
can take a look at those files and let me know if there is anything  
unclear, I will do my best to make them understandable and  
maintainable.  I have *not* hooked them up to any general suite of  
IPython tests, because I'm not totally clear on if/where that  
exists.  I would love to see them get run as part of a general  
checkin or, at the least, release creation process.



The Basic Structure of the Reorg
================================

I took the really, truly nasty logic from  
iplib.InteractiveShell._prefilter and moved it into a new module,  
prefilter.

As the prefilter module says in its docstring, it is: "responsible,  
primarily, for breaking the line up into useful pieces and triggering  
the appropriate handlers in iplib to do the actual transforming work."

To make much cleanup possible, I collected all the various bits of  
information about a given line (e.g. the raw line itself, the  
preChar, the iFun, etc), into an instance of a new class:  
prefilter.LineInfo.  This makes the interface to the various handlers  
and the stages of the prefilter much, much simpler.

The key stage of prefiltering now looks like so:

     for check in [ checkEmacs,
                    checkIPyAutocall,
                    checkMultiLineShell,
                    checkEscChars,
                    checkPythonChars,
                    checkAutomagic,
                    checkAlias,
                    checkAutocall,
                    ]:
         handler = check(line_info, ip)
         if handler:
             return handler(line_info)

A nice, explicit sequence of checks, which can be understood  
separately.  Each check returns either None or a handler to transform  
the line.


A Random Note
=============

  - I got the new IPyAutocall stuff, and added tests to both  
test_prefilter.py and test_handlers.py to verify the proper behavior


-Dan


From vivainio at gmail.com  Wed May 16 11:02:29 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 16 May 2007 17:02:29 +0200
Subject: [IPython-dev] Prefilter Reorg Committed
In-Reply-To: <2B5EDCAE-9C6C-481B-A51F-514780937B80@comcast.net>
References: <2B5EDCAE-9C6C-481B-A51F-514780937B80@comcast.net>
Message-ID: <46cb515a0705160802t31473effq72f22513c80bc50f@mail.gmail.com>

On 5/16/07, Dan Milstein <danmil at comcast.net> wrote:

> ...finally ;-)
>
> Okay, I just went ahead and committed it to the trunk (r. 2354).

Wow. What can I say, thanks for the high-quality submission that will
certainly be valuable as we proceed with breaking more things. :-)

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From vivainio at gmail.com  Wed May 16 11:24:13 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 16 May 2007 17:24:13 +0200
Subject: [IPython-dev] IPyAutocall-like dispatching with simplegeneric
Message-ID: <46cb515a0705160824s781211a7n8b3176217c327b22@mail.gmail.com>

Introduction of IPyAutocall made me think that we could make the
'command dispatching' more 'generic' (pun not intended) by harnessing
simplegeneric, already introduced to IPython by Walter
(external/simplegeneric.py).

http://cheeseshop.python.org/pypi/simplegeneric

That is, if the command part (iFun) is an object in user_ns that has
association created to a generic function, e.g. ipycmd, it would
always be called with specified arguments. This would avoid the need
to subclass IPyAutocall and override __call__, just tag the function
as generic and be done with it.

Something like (liberally copy-pasting from simplegeneric home page):

> @generic
... def ipycmd(item, ip, iFun, rest):
...     """Default implementation goes here"""
...     print "we don't really want a default implementation..."


OScmdmarker = object()

@ipycmd.when_object(OScmdmarker)
def callsyscmd(item, ip,iFun, rest):
  ip.system(iFun+' ' + rest)

cp = OScmdmarker
mv = OScmdmarker
ip.to_user_ns('cp mv')

@ipycmd.when_type(Macro):
def callmacro(item, ip, iFun, rest):
  ip.user_ns['_margv'] = rest
  ip.runlines(item.value)

I guess at least Walter might want to chip in, I have never actually
used this simplegeneric myself.

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From vivainio at gmail.com  Wed May 16 11:55:43 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 16 May 2007 17:55:43 +0200
Subject: [IPython-dev] IPyAutocall-like dispatching with simplegeneric
In-Reply-To: <46cb515a0705160824s781211a7n8b3176217c327b22@mail.gmail.com>
References: <46cb515a0705160824s781211a7n8b3176217c327b22@mail.gmail.com>
Message-ID: <46cb515a0705160855x2fcab690p7d7675d119c9e032@mail.gmail.com>

And more brainstorming... imagine if we got

@ipycmd.when_type(list):
def list_append(item, ip,iFun, rest):
 # check for 'list of strings, else raise ipapi.TryNext...
 item.append(rest)

Then you could accumulate a list by the shorthand:

l = []

l hello
l world

# l is now ['hello','world']

I bet you can think of quite a few enhancements like this, without
adding any code to core IPython itself.


From vivainio at gmail.com  Wed May 16 12:22:14 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 16 May 2007 18:22:14 +0200
Subject: [IPython-dev] IPyAutocall-like dispatching with simplegeneric
In-Reply-To: <46cb515a0705160855x2fcab690p7d7675d119c9e032@mail.gmail.com>
References: <46cb515a0705160824s781211a7n8b3176217c327b22@mail.gmail.com>
	<46cb515a0705160855x2fcab690p7d7675d119c9e032@mail.gmail.com>
Message-ID: <46cb515a0705160922g5e299aa8y34abaa4bcb4295a@mail.gmail.com>

And the stream of consciousness goes ever on...

We could also use a generic function for custom completers, something like:

@generic
def ipycomplete(item, event):
 raise TryNext


cd = object()

@ipycomplete.when_object(cd):
def complete_cd(item, event):
 # return a list of dirs, like with current custom cd completers...
 ...

This would again allow more elegant way to add completers than the
current registration approach.

Of course objects like this 'cd' should not be shows by %whos in order
to not confuse the user with too many variables.


From walter at livinglogic.de  Thu May 17 05:25:59 2007
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Thu, 17 May 2007 11:25:59 +0200
Subject: [IPython-dev] IPyAutocall-like dispatching with simplegeneric
In-Reply-To: <46cb515a0705160824s781211a7n8b3176217c327b22@mail.gmail.com>
References: <46cb515a0705160824s781211a7n8b3176217c327b22@mail.gmail.com>
Message-ID: <464C1FA7.4010309@livinglogic.de>

Ville M. Vainio wrote:

> Introduction of IPyAutocall made me think that we could make the
> 'command dispatching' more 'generic' (pun not intended) by harnessing
> simplegeneric, already introduced to IPython by Walter
> (external/simplegeneric.py).
> 
> http://cheeseshop.python.org/pypi/simplegeneric
> 
> That is, if the command part (iFun) is an object in user_ns that has
> association created to a generic function, e.g. ipycmd, it would
> always be called with specified arguments. This would avoid the need
> to subclass IPyAutocall and override __call__, just tag the function
> as generic and be done with it.
> 
> Something like (liberally copy-pasting from simplegeneric home page):
> 
>> @generic
> ... def ipycmd(item, ip, iFun, rest):
> ...     """Default implementation goes here"""
> ...     print "we don't really want a default implementation..."
> 
> 
> OScmdmarker = object()
> 
> @ipycmd.when_object(OScmdmarker)
> def callsyscmd(item, ip,iFun, rest):
>   ip.system(iFun+' ' + rest)
> 
> cp = OScmdmarker
> mv = OScmdmarker
> ip.to_user_ns('cp mv')

I don't see how callsyscmd() is supposed to distinguish between cp and 
mv commands. Both point to the same object.

> @ipycmd.when_type(Macro):
> def callmacro(item, ip, iFun, rest):
>   ip.user_ns['_margv'] = rest
>   ip.runlines(item.value)
> 
> I guess at least Walter might want to chip in, I have never actually
> used this simplegeneric myself.

As I see it simplegeneric is especially useful when the code is 
developed by three different parties: The one that develops the generic 
function, the one that develops the application classes and the one that 
develops the special implementation of the generic function for the 
application classes. However that's not the case here with IPython. I 
don't think that e.g. the Macro class is developed independently from 
IPython.

Servus,
    Walter



From gakusei at dakotacom.net  Thu May 17 16:27:58 2007
From: gakusei at dakotacom.net (Paul Mueller)
Date: Thu, 17 May 2007 13:27:58 -0700
Subject: [IPython-dev] patch to fix typo bug in ipipe
Message-ID: <20070517202758.GA6511@localhost.localdomain>

Hi,

I happened to find a small bug in ipipe.py (line 1183):
    if mode == "cell" or mode in "header" or mode == "footer":
                              ^^

Using "mode in" on a string has to be a mistake, since mode is used as
an enum and this is the only place in the file it's compared this way.

I've attached a patch to change "in" to "==".

Paul Mueller
-------------- next part --------------
Index: IPython/Extensions/ipipe.py
===================================================================
--- IPython/Extensions/ipipe.py	(revision 2359)
+++ IPython/Extensions/ipipe.py	(working copy)
@@ -1180,7 +1180,7 @@
     except IOError:
         name = "ifile"
         style = astyle.style_default
-    if mode == "cell" or mode in "header" or mode == "footer":
+    if mode == "cell" or mode == "header" or mode == "footer":
         abspath = repr(path._base(self.normpath()))
         if abspath.startswith("u"):
             abspath = abspath[2:-1]

From walter at livinglogic.de  Thu May 17 17:39:56 2007
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Thu, 17 May 2007 23:39:56 +0200
Subject: [IPython-dev] patch to fix typo bug in ipipe
In-Reply-To: <20070517202758.GA6511@localhost.localdomain>
References: <20070517202758.GA6511@localhost.localdomain>
Message-ID: <464CCBAC.20803@livinglogic.de>

Paul Mueller wrote:
> Hi,
> 
> I happened to find a small bug in ipipe.py (line 1183):
>     if mode == "cell" or mode in "header" or mode == "footer":
>                               ^^
> 
> Using "mode in" on a string has to be a mistake, since mode is used as
> an enum and this is the only place in the file it's compared this way.

You're right. The bug is fixed now in r2360.

> I've attached a patch to change "in" to "==".

Thanks for the bug report!

Servus,
    Walter


From hans_meine at gmx.net  Fri May 18 06:42:22 2007
From: hans_meine at gmx.net (Hans Meine)
Date: Fri, 18 May 2007 12:42:22 +0200
Subject: [IPython-dev] Regression bug in 0.8.x input filtering
Message-ID: <200705181242.22310.hans_meine@gmx.net>

Hi!

This won't come as a surprise AFAICS, but it's a great thing we have a test 
suite now.  Today, I tried to paste the following multi-line statement from 
epydoc's sources into ipython, and got an exception:

_SIGNATURE_RE = re.compile(
    # Class name (for builtin methods)
    r'^\s*((?P<self>\w+)\.)?' +
    # The function name (must match exactly) [XX] not anymore!
    r'(?P<func>\w+)' +
    # The parameters
    r'\((?P<params>(\s*\[?\s*\*{0,2}[\w\-\.]+(\s*=.+?)?'+
    r'(\s*\[?\s*,\s*\]?\s*\*{0,2}[\w\-\.]+(\s*=.+?)?)*\]*)?)\s*\)' +
    # The return value (optional)
    r'(\s*(->)\s*(?P<return>\S.*?))?'+
    # The end marker
    r'\s*(\n|\s+(--|<=+>)\s+|$|\.\s+|\.\n)')

The latest 0.8.x versions throw an error on the second non-comment 
continuation line:

IPython 0.8.1 -- 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]: _SIGNATURE_RE = re.compile(
   ...:     # Class name (for builtin methods)
   ...:     r'^\s*((?P<self>\w+)\.)?' +
   ...:     # The function name (must match exactly) [XX] not anymore!
   ...:     r'(?P<func>\w+)' +
------------------------------------------------------------
   File "<ipython console>", line 5
     _ip.magic(r"r '(?P<func>\w+)' +")
       ^
SyntaxError: invalid syntax

It works with 0.7.x though (I tried 0.7.1 and 0.7.3, both 0.8.0 and 0.8.1 
fail).

Ciao, /  /
     /--/
    /  / ANS


From anand at soe.ucsc.edu  Fri May 18 22:52:51 2007
From: anand at soe.ucsc.edu (Anand Patil)
Date: Fri, 18 May 2007 19:52:51 -0700
Subject: [IPython-dev] Strange property bug?
Message-ID: <464E6683.2010603@cse.ucsc.edu>

Hi all,

Here's a script I called 'test.py':

---------------------------------

class A(object):

    c=1

    def fget(self):
        self.c=self.c+1
        print 'Adding 1 to c'

    b=property(fget)
   
M = A()

----------------------


 From the regular Python shell, the A class works as expected:

Python 2.5 (r25:51918, Sep 19 2006, 08:49:13)
[GCC 4.0.1 (Apple Computer, Inc. build 5341)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> from test import *
 >>> M.c
1
 >>> M.b
Adding 1 to c
 >>> M.c
2
 >>>


But in IPython, the fget function seems to get called twice:

IPython 0.8.0 -- 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]: run test

In [2]: M.c
Out[2]: 1

In [3]: M.b
Adding 1 to c
Adding 1 to c

In [4]: M.c
Out[4]: 3

Any ideas?

Thanks,
Anand


From gakusei at dakotacom.net  Sat May 19 18:10:40 2007
From: gakusei at dakotacom.net (Paul Mueller)
Date: Sat, 19 May 2007 15:10:40 -0700
Subject: [IPython-dev] Strange property bug?
In-Reply-To: <464E6683.2010603@cse.ucsc.edu>
References: <464E6683.2010603@cse.ucsc.edu>
Message-ID: <20070519221039.GA5127@localhost.localdomain>

On Fri, May 18, 2007 at 07:52:51PM -0700, Anand Patil wrote:
> Hi all,
>
> Here's a script I called 'test.py':
>
> ---------------------------------
>
> class A(object):
>
>     c=1
>
>     def fget(self):
>         self.c=self.c+1
>         print 'Adding 1 to c'
>
>     b=property(fget)
>
> M = A()
>
> ----------------------
>
>
>  From the regular Python shell, the A class works as expected:

...

> But in IPython, the fget function seems to get called twice:

...

> Any ideas?

This is a result of autocall. Trying it with autocall on and off yields:

In [7]:%autocall
Automatic calling is: Smart

In [8]:M.b
Adding 1 to c
Adding 1 to c

In [9]:%autocall
Automatic calling is: OFF

In [10]:M.b
Adding 1 to c

If you want more info:

More specifically, the following line in ipython (in
IPython/prefilter.py's function checkAutocall) is indirectly
responsible, and mentions the problem:

oinfo = l_info.ofind(ip) # This can mutate state via getattr

It is only executed if autocall is on.

If autocall is on, ipython eventually calls getattr(M, 'b') as part of
determining if M.b should be autocalled, then later actually executes
M.b, so fget() ends up getting called twice.

Paul Mueller


From tocer.deng at gmail.com  Sun May 20 07:13:26 2007
From: tocer.deng at gmail.com (tocer)
Date: Sun, 20 May 2007 19:13:26 +0800
Subject: [IPython-dev] how to run a script in empty name space?
Message-ID: <46502D56.7050908@gmail.com>

Hi,

I do "run somescript.py" in IPython interpreter, then I print IPython 
interactive name space by doing "print dir()". I found the globle variants of 
the somescript.py is in it. But I wish it run in empty name space, not ipython 
name space. How can I do?

Any idea is appreciate.


From ian at showmedo.com  Sun May 20 11:19:43 2007
From: ian at showmedo.com (Ian Ozsvald)
Date: Sun, 20 May 2007 16:19:43 +0100 (BST)
Subject: [IPython-dev] IPython at WikiPedia
Message-ID: <3890.84.71.52.144.1179674383.squirrel@mail1.webfaction.com>

Dear all, I noticed that WikiPedia didn't have an IPython entry so I have
created a stub.  Given that other major dev environments have pages (e.g.
Wing, SPE) as do tools (e.g. matplotlib) I figured that IPython deserved
one too:
http://en.wikipedia.org/wiki/IPython

A WikiPedia editor had "expressed a concern that the subject of the
article does not satisfy the notability guideline".  Since my initial edit
another user has added citations which resulted in the 'concern' being
lifted.

I wonder if some of the good folks here would expand the entry such that
the IPython page becomes a permanent entry at Wikipedia?  I'm a long-time
user of IPython but I don't know too many of its features or history,
you'll all know a heck of a lot more than me.

Other wikipedia links that might give inspiration:
http://en.wikipedia.org/wiki/Matplotlib (perhaps could link to IPython?)
http://en.wikipedia.org/wiki/SciPy

I have already linked to IPython from the main Python entry:
http://en.wikipedia.org/wiki/Python_%28programming_language%29
and:
http://en.wikipedia.org/wiki/List_of_integrated_development_environments_for_Python_programming_language
http://en.wikipedia.org/wiki/Python_software#Packages_for_Python

Hoping to have inspired someone here,
Ian.


----
http://ShowMeDo.com
http://ShowMeDo.com/about (our pictures)
http://blog.ShowMeDo.com
http://forums.ShowMeDo.com
Ian at ShowMeDo.com


From vivainio at gmail.com  Mon May 21 02:45:45 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Mon, 21 May 2007 08:45:45 +0200
Subject: [IPython-dev] how to run a script in empty name space?
In-Reply-To: <46502D56.7050908@gmail.com>
References: <46502D56.7050908@gmail.com>
Message-ID: <46cb515a0705202345h396036a4oa82b50f0d0553beb@mail.gmail.com>

On 5/20/07, tocer <tocer.deng at gmail.com> wrote:

> I do "run somescript.py" in IPython interpreter, then I print IPython
> interactive name space by doing "print dir()". I found the globle variants of
> the somescript.py is in it. But I wish it run in empty name space, not ipython
> name space. How can I do?

How about running them in a whole new process, i.e. 'python somescript.py'.

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From vivainio at gmail.com  Mon May 21 04:00:03 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Mon, 21 May 2007 10:00:03 +0200
Subject: [IPython-dev] Prefilter Reorg Committed
In-Reply-To: <2B5EDCAE-9C6C-481B-A51F-514780937B80@comcast.net>
References: <2B5EDCAE-9C6C-481B-A51F-514780937B80@comcast.net>
Message-ID: <46cb515a0705210100r7f0687f9udd561189b11ddfe4@mail.gmail.com>

On 5/16/07, Dan Milstein <danmil at comcast.net> wrote:

> ...finally ;-)
>
> Okay, I just went ahead and committed it to the trunk (r. 2354).

Possible regression: "cd /" now gives syntaxerror, instead of being
caught as a proper magic command. cd \ and other cd invocations work
ok.

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From tocer.deng at gmail.com  Mon May 21 05:42:45 2007
From: tocer.deng at gmail.com (tocer)
Date: Mon, 21 May 2007 17:42:45 +0800
Subject: [IPython-dev] how to run a script in empty name space?
In-Reply-To: <46cb515a0705202345h396036a4oa82b50f0d0553beb@mail.gmail.com>
References: <46502D56.7050908@gmail.com>
	<46cb515a0705202345h396036a4oa82b50f0d0553beb@mail.gmail.com>
Message-ID: <46516995.5040103@gmail.com>

Yes, but I can't take advantage of all property of IPython. In Ipython help 
documents, I found it in magic run command usage:

-i: run the file in IPython's namespace instead of an empty one. This is useful 
if you are experimenting with code written in a text editor which depends on 
variables defined interactively.

how to understand that?

Ville M. Vainio wrote::
> On 5/20/07, tocer <tocer.deng at gmail.com> wrote:
> 
>> I do "run somescript.py" in IPython interpreter, then I print IPython
>> interactive name space by doing "print dir()". I found the globle 
>> variants of
>> the somescript.py is in it. But I wish it run in empty name space, not 
>> ipython
>> name space. How can I do?
> 
> How about running them in a whole new process, i.e. 'python somescript.py'.
> 


From vivainio at gmail.com  Mon May 21 13:53:32 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Mon, 21 May 2007 19:53:32 +0200
Subject: [IPython-dev] how to run a script in empty name space?
In-Reply-To: <46516995.5040103@gmail.com>
References: <46502D56.7050908@gmail.com>
	<46cb515a0705202345h396036a4oa82b50f0d0553beb@mail.gmail.com>
	<46516995.5040103@gmail.com>
Message-ID: <46cb515a0705211053m413b9d27o2f32860b22096c47@mail.gmail.com>

On 5/21/07, tocer <tocer.deng at gmail.com> wrote:

> Yes, but I can't take advantage of all property of IPython. In Ipython help

Yes you can, you can launch your script from ipython if you have
"python" available as an alias. Or do !python myscript.py

> documents, I found it in magic run command usage:
>
> -i: run the file in IPython's namespace instead of an empty one. This is useful
> if you are experimenting with code written in a text editor which depends on
> variables defined interactively.

Yes, this means the namespace won't be clean *in the beginning*.
Either way, it won't be clean in the end.

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From danmil at comcast.net  Wed May 23 11:38:23 2007
From: danmil at comcast.net (Dan Milstein)
Date: Wed, 23 May 2007 11:38:23 -0400
Subject: [IPython-dev] What To Do With a Problem Like 'cd /'?
In-Reply-To: <46cb515a0705210100r7f0687f9udd561189b11ddfe4@mail.gmail.com>
References: <2B5EDCAE-9C6C-481B-A51F-514780937B80@comcast.net>
	<46cb515a0705210100r7f0687f9udd561189b11ddfe4@mail.gmail.com>
Message-ID: <5DC476FE-5D24-4353-A19F-2C0E131601A7@comcast.net>

As Ville noted below, subsequent to the prefilter reorg, 'cd /' now  
gives a syntax error, whereas before, it successfully expanded to an  
automagic call.

I've tracked the issue down, but I'm not sure what the proper  
behavior should be.

The problem is that the system is now being far more careful about  
paying attention to possible python operators on a line.  This  
started with a commit by Fernando a month+ ago:

http://projects.scipy.org/ipython/ipython/changeset/2207

This tries to avoid certain bad autocall issues by checking for the  
following chars as the start of the rest of a line, and it finds one,  
just handling the line normally:

'!=()<>+*/%^&|'

Note how '/' is now in there.  When I reorg'd things, I put that  
check in prefilter.checkPythonChars, which gets called *before*  
checkAutomagic.  Thus, when you type:

  : cd /

The system sees the /, and says, basically, "Oh, this looks like it  
might be a valid python expression, so I'm going to just handle it  
normally (and thus not expand the magic cd)".

I'm not sure if this should or should not be 'fixed'.  I mean, OTOH,  
'cd /' is pretty damn useful.  On the other hand, there are some  
weird interactions among the various namespaces, and being  
consistently careful and respectful of possible python operators  
seems like a good, safe practice.

You can work around it with "cd '/'" or "cd \/" (though, ugh).

Or I can maybe special case assignment separately from all the other  
python chars, and only check for that before expanding automagics (so  
that the full pythonChar check just comes before autocall  
expansion).  I *think* that would be safe, but I would not swear to it.

What do people think?

-Dan






On May 21, 2007, at 4:00 AM, Ville M. Vainio wrote:

> On 5/16/07, Dan Milstein <danmil at comcast.net> wrote:
>
>> ...finally ;-)
>>
>> Okay, I just went ahead and committed it to the trunk (r. 2354).
>
> Possible regression: "cd /" now gives syntaxerror, instead of being
> caught as a proper magic command. cd \ and other cd invocations work
> ok.
>
> -- 
> Ville M. Vainio - vivainio.googlepages.com
> blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'



From vivainio at gmail.com  Wed May 23 12:46:14 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 23 May 2007 18:46:14 +0200
Subject: [IPython-dev] What To Do With a Problem Like 'cd /'?
In-Reply-To: <5DC476FE-5D24-4353-A19F-2C0E131601A7@comcast.net>
References: <2B5EDCAE-9C6C-481B-A51F-514780937B80@comcast.net>
	<46cb515a0705210100r7f0687f9udd561189b11ddfe4@mail.gmail.com>
	<5DC476FE-5D24-4353-A19F-2C0E131601A7@comcast.net>
Message-ID: <46cb515a0705230946r7bee8a1bk3ff860f694393229@mail.gmail.com>

On 5/23/07, Dan Milstein <danmil at comcast.net> wrote:

> This tries to avoid certain bad autocall issues by checking for the
> following chars as the start of the rest of a line, and it finds one,
> just handling the line normally:
>
> '!=()<>+*/%^&|'
>
> Note how '/' is now in there.  When I reorg'd things, I put that
> check in prefilter.checkPythonChars, which gets called *before*
> checkAutomagic.  Thus, when you type:

I think we just need to check for automagic before this. The automagic
can very well "give up" if the "function" is also in user_ns, without
need for checks like this.

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From vivainio at gmail.com  Wed May 23 13:14:00 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 23 May 2007 19:14:00 +0200
Subject: [IPython-dev] standalone ipython exe (py2exe)
Message-ID: <46cb515a0705231014k4da880b2ufbe21bdb1372b6f2@mail.gmail.com>

I started up a little experimental setup script, "exesetup.py". With
py2exe, it can be used ts create standalone ipython executables that
don't require python, pyreadline or anything else installed. It kinda
sorta seems to work, but please try it out.

I created this because I myself need ipython I can put on an mmc card
(for shell use - it pains me to use cmd.exe these days).

What needs to be done is to read ipy_user_conf.py and profiles from
the ipython.exe directory, instead of creating a new dir under HOME.

And yes, this is a bit like Movable Python, but only focuses on
ipython, only aims at doing the "trivial" thing and is under BSD
license.

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From danmil at comcast.net  Wed May 23 13:38:40 2007
From: danmil at comcast.net (Dan Milstein)
Date: Wed, 23 May 2007 13:38:40 -0400
Subject: [IPython-dev] What To Do With a Problem Like 'cd /'?
In-Reply-To: <46cb515a0705230946r7bee8a1bk3ff860f694393229@mail.gmail.com>
References: <2B5EDCAE-9C6C-481B-A51F-514780937B80@comcast.net>
	<46cb515a0705210100r7f0687f9udd561189b11ddfe4@mail.gmail.com>
	<5DC476FE-5D24-4353-A19F-2C0E131601A7@comcast.net>
	<46cb515a0705230946r7bee8a1bk3ff860f694393229@mail.gmail.com>
Message-ID: <FF466FC0-45B6-4FC0-B904-75CA20E5053F@comcast.net>

I set this up basically as you described below (and added tests for  
it).  A few caveats:

  - We *do* need to check for assignment, at least, before automagic  
expansion, so that the user can do:

  cd = 3

And not have it get eval'd as magic.  (Ditto for cd,de = 2,3)

(the automagic check does look to see if the 'function' is shadowed  
by something in user_ns, but we need to make it possible for the user  
put the thing into the user_ns in the first place).


  - Do you also want to treat aliases similarly?

Meaning: should we allow alias expansion on lines which look like:

   an_alias /

Now that I've got assignment split out from other python ops, that's  
trivial to add, but I haven't done it yet (mostly because I'm a tiny  
bit fuzzy on the whole alias/magic divide).


-Dan

On May 23, 2007, at 12:46 PM, Ville M. Vainio wrote:

> On 5/23/07, Dan Milstein <danmil at comcast.net> wrote:
>
>> This tries to avoid certain bad autocall issues by checking for the
>> following chars as the start of the rest of a line, and it finds one,
>> just handling the line normally:
>>
>> '!=()<>+*/%^&|'
>>
>> Note how '/' is now in there.  When I reorg'd things, I put that
>> check in prefilter.checkPythonChars, which gets called *before*
>> checkAutomagic.  Thus, when you type:
>
> I think we just need to check for automagic before this. The automagic
> can very well "give up" if the "function" is also in user_ns, without
> need for checks like this.
>
> -- 
> Ville M. Vainio - vivainio.googlepages.com
> blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'



From vivainio at gmail.com  Wed May 23 14:53:36 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 23 May 2007 20:53:36 +0200
Subject: [IPython-dev] What To Do With a Problem Like 'cd /'?
In-Reply-To: <FF466FC0-45B6-4FC0-B904-75CA20E5053F@comcast.net>
References: <2B5EDCAE-9C6C-481B-A51F-514780937B80@comcast.net>
	<46cb515a0705210100r7f0687f9udd561189b11ddfe4@mail.gmail.com>
	<5DC476FE-5D24-4353-A19F-2C0E131601A7@comcast.net>
	<46cb515a0705230946r7bee8a1bk3ff860f694393229@mail.gmail.com>
	<FF466FC0-45B6-4FC0-B904-75CA20E5053F@comcast.net>
Message-ID: <46cb515a0705231153t6c3dd6e4y9a732067e2b83915@mail.gmail.com>

On 5/23/07, Dan Milstein <danmil at comcast.net> wrote:

>   - Do you also want to treat aliases similarly?
>
> Meaning: should we allow alias expansion on lines which look like:
>
>    an_alias /

Yes. Performing anything else than assignment on a non-existing name
is illegal python anyway.

> Now that I've got assignment split out from other python ops, that's
> trivial to add, but I haven't done it yet (mostly because I'm a tiny
> bit fuzzy on the whole alias/magic divide).

That's because the divide is not technically necessary. My evil
masterplan is to to get rid of the concepts of "alias" (though not the
keyword!) at some point. At least on source code level, read my
previous simplegeneric mail if interested.

In the meantime, a handy alias to use for ipython devs:

$ alias timeline start http://projects.scipy.org/ipython/ipython/timeline
$ %store timeline

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From vivainio at gmail.com  Wed May 23 16:50:57 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 23 May 2007 22:50:57 +0200
Subject: [IPython-dev] standalone ipython exe (py2exe)
In-Reply-To: <46cb515a0705231014k4da880b2ufbe21bdb1372b6f2@mail.gmail.com>
References: <46cb515a0705231014k4da880b2ufbe21bdb1372b6f2@mail.gmail.com>
Message-ID: <46cb515a0705231350r57920836se487d7832e513f26@mail.gmail.com>

On 5/23/07, Ville M. Vainio <vivainio at gmail.com> wrote:

> I started up a little experimental setup script, "exesetup.py". With
> py2exe, it can be used ts create standalone ipython executables that
> don't require python, pyreadline or anything else installed. It kinda
> sorta seems to work, but please try it out.

It's now a pretty neat ~ 8 meg package:

D:\ipython\dist>ls -s
total 7733
 352 MSVCR71.dll     80 bz2.pyd             16 select.pyd
  80 _ctypes.pyd     16 ipython.exe        464 unicodedata.pyd
 320 _hashlib.pyd  3392 library.zip          5 w9xpopen.exe
  64 _socket.pyd   2064 python25.dll        16 win32clipboard.pyd
 640 _ssl.pyd       112 pywintypes25.dll   112 win32security.pyd

D:\ipython\dist>ipython -p sh
Py 2.5.1c1 (r251c1:54692, Apr  5 2007, 09:19:18) [MSC v.1310 32 bit (Intel)] IPy
 0.8.2.svn.r2355
[ipython\dist]|1> import IPython
[ipython\dist]|2> IPy
IPython     ipython.exe
[ipython\dist]|2> IPython
              <2> <module 'IPython' from 'D:\ipython\dist\library.zip\IPython\__
init__.pyc'>


All the stuff (pyreadline, IPython, stdlib etc.) is in library.zip.

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From danmil at comcast.net  Wed May 23 17:00:20 2007
From: danmil at comcast.net (Dan Milstein)
Date: Wed, 23 May 2007 17:00:20 -0400
Subject: [IPython-dev] What To Do With a Problem Like 'cd /'?
In-Reply-To: <46cb515a0705231153t6c3dd6e4y9a732067e2b83915@mail.gmail.com>
References: <2B5EDCAE-9C6C-481B-A51F-514780937B80@comcast.net>
	<46cb515a0705210100r7f0687f9udd561189b11ddfe4@mail.gmail.com>
	<5DC476FE-5D24-4353-A19F-2C0E131601A7@comcast.net>
	<46cb515a0705230946r7bee8a1bk3ff860f694393229@mail.gmail.com>
	<FF466FC0-45B6-4FC0-B904-75CA20E5053F@comcast.net>
	<46cb515a0705231153t6c3dd6e4y9a732067e2b83915@mail.gmail.com>
Message-ID: <21D58A35-4BDA-4243-9CBA-074046A44020@comcast.net>

Got it. Done + committed + a test added.

-Dan

On May 23, 2007, at 2:53 PM, Ville M. Vainio wrote:

> On 5/23/07, Dan Milstein <danmil at comcast.net> wrote:
>
>>   - Do you also want to treat aliases similarly?
>>
>> Meaning: should we allow alias expansion on lines which look like:
>>
>>    an_alias /
>
> Yes. Performing anything else than assignment on a non-existing name
> is illegal python anyway.
>
>> Now that I've got assignment split out from other python ops, that's
>> trivial to add, but I haven't done it yet (mostly because I'm a tiny
>> bit fuzzy on the whole alias/magic divide).
>
> That's because the divide is not technically necessary. My evil
> masterplan is to to get rid of the concepts of "alias" (though not the
> keyword!) at some point. At least on source code level, read my
> previous simplegeneric mail if interested.
>
> In the meantime, a handy alias to use for ipython devs:
>
> $ alias timeline start http://projects.scipy.org/ipython/ipython/ 
> timeline
> $ %store timeline
>
> -- 
> Ville M. Vainio - vivainio.googlepages.com
> blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'



From hans_meine at gmx.net  Wed May 23 17:16:07 2007
From: hans_meine at gmx.net (Hans Meine)
Date: Wed, 23 May 2007 23:16:07 +0200
Subject: [IPython-dev] Regression bug in 0.8.x input filtering
In-Reply-To: <200705181242.22310.hans_meine@gmx.net>
References: <200705181242.22310.hans_meine@gmx.net>
Message-ID: <200705232316.12588.hans_meine@gmx.net>

Hi again!

On Freitag 18 Mai 2007, Hans Meine wrote:
> This won't come as a surprise AFAICS, but it's a great thing we have a test
> suite now.  Today, I tried to paste the following multi-line statement from
> epydoc's sources into ipython, and got an exception:
>
> [...]

Now that the "cd /" is solved, I wonder if nobody cares about this regression 
I reported last friday?  (Or did I do sth. wrong by posting it here?  I am 
very short on time and would like to avoid registering with any trackers..)

-- 
Ciao, /  /                                                    .o.
     /--/                                                     ..o
    /  / ANS                                                  ooo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20070523/97920b92/attachment.sig>

From vivainio at gmail.com  Wed May 23 17:23:30 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 23 May 2007 23:23:30 +0200
Subject: [IPython-dev] Regression bug in 0.8.x input filtering
In-Reply-To: <200705181242.22310.hans_meine@gmx.net>
References: <200705181242.22310.hans_meine@gmx.net>
Message-ID: <46cb515a0705231423h71a210cx5420a3095442a620@mail.gmail.com>

On 5/18/07, Hans Meine <hans_meine at gmx.net> wrote:

>    ...:     r'^\s*((?P<self>\w+)\.)?' +
>    ...:     # The function name (must match exactly) [XX] not anymore!
>    ...:     r'(?P<func>\w+)' +
> ------------------------------------------------------------
>    File "<ipython console>", line 5
>      _ip.magic(r"r '(?P<func>\w+)' +")

Ah, it's the magic %r, "repeat previous input".

We should demand whitespace between magic / alias and the "rest", or
alternatively we do a quick fix and just delete the magic "r". Who
uses it anyway? That's what "up + enter" is for.

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From vivainio at gmail.com  Wed May 23 17:16:31 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Wed, 23 May 2007 23:16:31 +0200
Subject: [IPython-dev] What To Do With a Problem Like 'cd /'?
In-Reply-To: <21D58A35-4BDA-4243-9CBA-074046A44020@comcast.net>
References: <2B5EDCAE-9C6C-481B-A51F-514780937B80@comcast.net>
	<46cb515a0705210100r7f0687f9udd561189b11ddfe4@mail.gmail.com>
	<5DC476FE-5D24-4353-A19F-2C0E131601A7@comcast.net>
	<46cb515a0705230946r7bee8a1bk3ff860f694393229@mail.gmail.com>
	<FF466FC0-45B6-4FC0-B904-75CA20E5053F@comcast.net>
	<46cb515a0705231153t6c3dd6e4y9a732067e2b83915@mail.gmail.com>
	<21D58A35-4BDA-4243-9CBA-074046A44020@comcast.net>
Message-ID: <46cb515a0705231416j5bfed510x4c7a519d8b8426eb@mail.gmail.com>

On 5/23/07, Dan Milstein <danmil at comcast.net> wrote:

> Got it. Done + committed + a test added.

Excellent. Works for me. Now I have my comfy old shell behaviour back :)

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From danmil at comcast.net  Wed May 23 17:42:51 2007
From: danmil at comcast.net (Dan Milstein)
Date: Wed, 23 May 2007 17:42:51 -0400
Subject: [IPython-dev] Regression bug in 0.8.x input filtering
In-Reply-To: <46cb515a0705231423h71a210cx5420a3095442a620@mail.gmail.com>
References: <200705181242.22310.hans_meine@gmx.net>
	<46cb515a0705231423h71a210cx5420a3095442a620@mail.gmail.com>
Message-ID: <E0B20D80-6D8A-4F38-88B0-E27BB86C7499@comcast.net>

Hmm.  I can, I think without too much pain, force whitespace between  
the possible magic/alias/autocall term and the rest of the line, but  
I am just a bit hesitant, because I think that's sort of new  
behavior.  The old pattern matching was very, very hard to fully  
comprehend, but I don't think that's what it did (at least, not in  
general).  I mean, if this is a regression, clearly it did  
*something* like that, but I'd like to fully understand it before I  
make a serious change like that.

(Or maybe people like Ville's fine, fine idea about getting rid of %r  
as a magic -- IMHO, we're kind of asking for trouble given that  
r'something' is valid python).

Also Hans: can you resend the original email to me?  I can't see to  
find it, for some reason.

-Dan

On May 23, 2007, at 5:23 PM, Ville M. Vainio wrote:

> On 5/18/07, Hans Meine <hans_meine at gmx.net> wrote:
>
>>    ...:     r'^\s*((?P<self>\w+)\.)?' +
>>    ...:     # The function name (must match exactly) [XX] not  
>> anymore!
>>    ...:     r'(?P<func>\w+)' +
>> ------------------------------------------------------------
>>    File "<ipython console>", line 5
>>      _ip.magic(r"r '(?P<func>\w+)' +")
>
> Ah, it's the magic %r, "repeat previous input".
>
> We should demand whitespace between magic / alias and the "rest", or
> alternatively we do a quick fix and just delete the magic "r". Who
> uses it anyway? That's what "up + enter" is for.
>
> -- 
> Ville M. Vainio - vivainio.googlepages.com
> blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev



From fperez.net at gmail.com  Thu May 24 02:23:24 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 24 May 2007 00:23:24 -0600
Subject: [IPython-dev] Regression bug in 0.8.x input filtering
In-Reply-To: <E0B20D80-6D8A-4F38-88B0-E27BB86C7499@comcast.net>
References: <200705181242.22310.hans_meine@gmx.net>
	<46cb515a0705231423h71a210cx5420a3095442a620@mail.gmail.com>
	<E0B20D80-6D8A-4F38-88B0-E27BB86C7499@comcast.net>
Message-ID: <db6b5ecc0705232323ydd8eb8cgbce7ed4d12815db9@mail.gmail.com>

On 5/23/07, Dan Milstein <danmil at comcast.net> wrote:
> Hmm.  I can, I think without too much pain, force whitespace between
> the possible magic/alias/autocall term and the rest of the line, but
> I am just a bit hesitant, because I think that's sort of new
> behavior.  The old pattern matching was very, very hard to fully
> comprehend, but I don't think that's what it did (at least, not in
> general).  I mean, if this is a regression, clearly it did
> *something* like that, but I'd like to fully understand it before I
> make a serious change like that.
>
> (Or maybe people like Ville's fine, fine idea about getting rid of %r
> as a magic -- IMHO, we're kind of asking for trouble given that
> r'something' is valid python).

Well, I don't see why 'r' as a magic should cause any special problems
that other magics don't have.  All magic calls should have at least
one space between their name and their arguments, just like a normal
shell works:

# This works:
maqroll[~/test]> ls foo*
foo.ipy  foo.py  foo.tpl.txt  foo.txt

# but omitting the spaces makes a shell unhappy:
maqroll[~/test]> lsfoo*
lsfoo*: No match.
maqroll[~/test]> ls'foo*'
lsfoo*: Command not found.


So I don't see anything special in %r, other than its name being a
single letter.  If we delete it, do we somehow want to prohibit
single-letter magic names?  Of course not.

The 'grammar' for magics should be:

[%]name [-options] [args]

where the % is optional only if automagic is on, the space is
mandatory, the argument string is split using the same rules that a
shell uses (we do it via shlex.split), and python variables are
expanded into their string form via $ for convenience.

Since magics are meant for quick control of things, they shouldn't
really be themselves too complicated (monstrosities like %run
notwithstanding).  Ideally, the magic should be a thin, -option
controlled convenience wrapper around a library of normal Python
functions that do the real work.  Said functions could then be used by
code without jumping through as many contortions (with full python
types for inputs as well as regular keywords),  and have a magic for
convenience calling (perhaps only of a simplified form).

The original magics as they are today, with a single argstring, are
somewhat of a historical artifact but they match well traditional
shell behavior, and they are thus fast and convenient for interactive
use.  What we need to do is to make it easier to integrate such
convenience on top of a more robust underlying layer that really uses
the Python language in full.

Cheers,

f


From fperez.net at gmail.com  Thu May 24 02:28:49 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 24 May 2007 00:28:49 -0600
Subject: [IPython-dev] standalone ipython exe (py2exe)
In-Reply-To: <46cb515a0705231014k4da880b2ufbe21bdb1372b6f2@mail.gmail.com>
References: <46cb515a0705231014k4da880b2ufbe21bdb1372b6f2@mail.gmail.com>
Message-ID: <db6b5ecc0705232328s5aefb684t6a6d920d3b5259bc@mail.gmail.com>

On 5/23/07, Ville M. Vainio <vivainio at gmail.com> wrote:
> I started up a little experimental setup script, "exesetup.py". With
> py2exe, it can be used ts create standalone ipython executables that
> don't require python, pyreadline or anything else installed. It kinda
> sorta seems to work, but please try it out.
>
> I created this because I myself need ipython I can put on an mmc card
> (for shell use - it pains me to use cmd.exe these days).

Great!  Once it's a bit more tested,  you should make a page on the
wiki for it and announce it in the News page.  I could see this being
quite useful for many people.

In addition, wrapping numpy and matplotlib along with it would make
for a fantastic matlab-like-lite-in-a-box that could come in very
handy in many situations.

Cheers,

f


From danmil at comcast.net  Thu May 24 10:41:00 2007
From: danmil at comcast.net (Dan Milstein)
Date: Thu, 24 May 2007 10:41:00 -0400
Subject: [IPython-dev] Regression bug in 0.8.x input filtering
In-Reply-To: <db6b5ecc0705232323ydd8eb8cgbce7ed4d12815db9@mail.gmail.com>
References: <200705181242.22310.hans_meine@gmx.net>
	<46cb515a0705231423h71a210cx5420a3095442a620@mail.gmail.com>
	<E0B20D80-6D8A-4F38-88B0-E27BB86C7499@comcast.net>
	<db6b5ecc0705232323ydd8eb8cgbce7ed4d12815db9@mail.gmail.com>
Message-ID: <15785272-E89E-48EA-A022-969EF465D9EB@comcast.net>

Okay, I'm sold on the %r as a reasonable magic, and whitespace  
splitting as a reasonable req.

In looking to implement it, tho, I bumped up against something else  
-- trailing qmark fun.

Specifically, we jump through some hoops right now so that:

 > !thing?

and

 > !!thing?

Trigger the shell handler, and *not* the help handler.  This was  
particularly important/useful because the qmark is a part of some  
valid shell commands.

For the exact two examples above, this is not... easy... to get right  
if I start requiring the whitespace between the iFun and theRest of  
the line.  I'm not saying it's impossible, but we're starting to move  
from regex matching into parsing territory at that point.

But, as Fernando says, the shell generally requires whitespace, so  
maybe it's okay if !thing? triggers help, as long as:

 > !thing (.*)?

and

 > !!thing (.*)?

trigger the shell handler.  *That* I can fit into the current  
framework without too much pain.

Does that make sense / what do you all think?

-D



On May 24, 2007, at 2:23 AM, Fernando Perez wrote:

> On 5/23/07, Dan Milstein <danmil at comcast.net> wrote:
>> Hmm.  I can, I think without too much pain, force whitespace between
>> the possible magic/alias/autocall term and the rest of the line, but
>> I am just a bit hesitant, because I think that's sort of new
>> behavior.  The old pattern matching was very, very hard to fully
>> comprehend, but I don't think that's what it did (at least, not in
>> general).  I mean, if this is a regression, clearly it did
>> *something* like that, but I'd like to fully understand it before I
>> make a serious change like that.
>>
>> (Or maybe people like Ville's fine, fine idea about getting rid of %r
>> as a magic -- IMHO, we're kind of asking for trouble given that
>> r'something' is valid python).
>
> Well, I don't see why 'r' as a magic should cause any special problems
> that other magics don't have.  All magic calls should have at least
> one space between their name and their arguments, just like a normal
> shell works:
>
> # This works:
> maqroll[~/test]> ls foo*
> foo.ipy  foo.py  foo.tpl.txt  foo.txt
>
> # but omitting the spaces makes a shell unhappy:
> maqroll[~/test]> lsfoo*
> lsfoo*: No match.
> maqroll[~/test]> ls'foo*'
> lsfoo*: Command not found.
>
>
> So I don't see anything special in %r, other than its name being a
> single letter.  If we delete it, do we somehow want to prohibit
> single-letter magic names?  Of course not.
>
> The 'grammar' for magics should be:
>
> [%]name [-options] [args]
>
> where the % is optional only if automagic is on, the space is
> mandatory, the argument string is split using the same rules that a
> shell uses (we do it via shlex.split), and python variables are
> expanded into their string form via $ for convenience.
>
> Since magics are meant for quick control of things, they shouldn't
> really be themselves too complicated (monstrosities like %run
> notwithstanding).  Ideally, the magic should be a thin, -option
> controlled convenience wrapper around a library of normal Python
> functions that do the real work.  Said functions could then be used by
> code without jumping through as many contortions (with full python
> types for inputs as well as regular keywords),  and have a magic for
> convenience calling (perhaps only of a simplified form).
>
> The original magics as they are today, with a single argstring, are
> somewhat of a historical artifact but they match well traditional
> shell behavior, and they are thus fast and convenient for interactive
> use.  What we need to do is to make it easier to integrate such
> convenience on top of a more robust underlying layer that really uses
> the Python language in full.
>
> Cheers,
>
> f



From hans_meine at gmx.net  Thu May 24 10:50:48 2007
From: hans_meine at gmx.net (Hans Meine)
Date: Thu, 24 May 2007 16:50:48 +0200
Subject: [IPython-dev] Regression bug in 0.8.x input filtering
In-Reply-To: <15785272-E89E-48EA-A022-969EF465D9EB@comcast.net>
References: <200705181242.22310.hans_meine@gmx.net>
	<db6b5ecc0705232323ydd8eb8cgbce7ed4d12815db9@mail.gmail.com>
	<15785272-E89E-48EA-A022-969EF465D9EB@comcast.net>
Message-ID: <200705241650.53129.hans_meine@gmx.net>

On Donnerstag 24 Mai 2007, Dan Milstein wrote:
> Okay, I'm sold on the %r as a reasonable magic, and whitespace 
> splitting as a reasonable req.
I too think that whitespace splitting is reasonable, but I would never use %r.  
OTOH, I see that every ipython user has his/her own habits.

> Specifically, we jump through some hoops right now so that:
>  > !thing?
>
> and
>
>  > !!thing?
>
> Trigger the shell handler, and *not* the help handler.  This was
> particularly important/useful because the qmark is a part of some
> valid shell commands.
Part of globs in particular.  globs are not evaluated by the shell in the 
first (command) word, so I would suggest..
> maybe it's okay if !thing? triggers help, as long as:
>  > !thing (.*)?
>
> and
>
>  > !!thing (.*)?
exactly this.

-- 
Ciao, /  /                                                    .o.
     /--/                                                     ..o
    /  / ANS                                                  ooo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20070524/445c4cff/attachment.sig>

From vivainio at gmail.com  Thu May 24 14:53:06 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Thu, 24 May 2007 20:53:06 +0200
Subject: [IPython-dev] %history and %rep
Message-ID: <46cb515a0705241153i4ed68c09u5639d09194ffbff@mail.gmail.com>

Here's an idea for uber replacement for %r:

%hist string

=> show list of history elements that match the pattern "string"

%rep 43

=> Run / get for editing line 43

%rep 3-5 7-8

run those lines. Like macro without, er, the macro.

Speaking of which, I'd also like to nuke / deprecate %history and
leave only %hist, in the name of general magic namespace depollution.

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From vivainio at gmail.com  Thu May 24 15:40:19 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Thu, 24 May 2007 21:40:19 +0200
Subject: [IPython-dev] Autoload brainstorming
Message-ID: <46cb515a0705241240i4b9b97edx528f21d4e4ab7969@mail.gmail.com>

Sorry for spamming the lists, but I'm kinda on the flow here ;-)

I was thinking of how to implement the autoloading, and namely
autoload registry. I believe we could add a greppable block to the
modules that would be executed by IPython on "scanning" phase (without
having to import the module).

I.e. ipy_pydb.py extension would have the block:

"""
<ipython_scan>

ip.autoload("pydb", "ipy_pydb")

# ok, this is artificial in ipy_pydb, but for the sake of example..
ip.autoload("bzr", "ipy_app_completers")
</ipython_scan>
"""

Then we would have an autoload registry (in _ip.db) that is consulted
when we see "%pydb bah" or "%pydb <tab>", to see what module will be
imported before magic execution or tab completion will "work".

I would only want to list the "autoloadable" magics (as opposed to
already loaded magics) in tab completer when the user has started
typing the magic name with %.

This should seriously unbloat IPython, while allowing intoduction of
zillions of magics.

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From vivainio at gmail.com  Thu May 24 16:27:27 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Thu, 24 May 2007 22:27:27 +0200
Subject: [IPython-dev] %history and %rep
In-Reply-To: <46cb515a0705241153i4ed68c09u5639d09194ffbff@mail.gmail.com>
References: <46cb515a0705241153i4ed68c09u5639d09194ffbff@mail.gmail.com>
Message-ID: <46cb515a0705241327h6e0ad1d1v6ba7943a861cd00@mail.gmail.com>

After some thought, here's my suggestion:

%rep PAT

- If many hist lines match PAT, display them. If only one matches, set
it as current input line. Kinda like %hist PAT I proposed.

%rep NUMBER

- set history line #NUMBER as current input line

%rep

- directly execute last line? for readline-handicapped?

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From vivainio at gmail.com  Thu May 24 16:30:42 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Thu, 24 May 2007 22:30:42 +0200
Subject: [IPython-dev] %history and %rep
In-Reply-To: <46cb515a0705241327h6e0ad1d1v6ba7943a861cd00@mail.gmail.com>
References: <46cb515a0705241153i4ed68c09u5639d09194ffbff@mail.gmail.com>
	<46cb515a0705241327h6e0ad1d1v6ba7943a861cd00@mail.gmail.com>
Message-ID: <46cb515a0705241330n26307a94m24c63d22332562f8@mail.gmail.com>

Yeah, forgot the 3-5 macro syntax for directly executing specified
lines. See "%save?"

And yes, we would leave users who want to grep for numbers in history
crying in the dust, as far as %rep goes.

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From vivainio at gmail.com  Thu May 24 17:11:34 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Thu, 24 May 2007 23:11:34 +0200
Subject: [IPython-dev] %history and %rep
In-Reply-To: <46cb515a0705241327h6e0ad1d1v6ba7943a861cd00@mail.gmail.com>
References: <46cb515a0705241153i4ed68c09u5639d09194ffbff@mail.gmail.com>
	<46cb515a0705241327h6e0ad1d1v6ba7943a861cd00@mail.gmail.com>
Message-ID: <46cb515a0705241411s5a0a09dse5f96113496779c1@mail.gmail.com>

On 5/24/07, Ville M. Vainio <vivainio at gmail.com> wrote:

> %rep
>
> - directly execute last line? for readline-handicapped?

Ok, that was a bad idea. Readline-handicapped people won't use
ipython, probably.

%rep should use str(_) as the input line. I.e. the stringized version
of the last result. Ever looked at those strings on variables that are
so close yet so far, i.e. require you to do the productivity-killing
chore of mouse-console-copypaste? Now you could do:

$ l = ["hei", "vaan"]

$ "".join(l)

==> heivaan

$ rep

$ heivaan_ <== cursor blinking

I've often wanted to construct the input line and then edit it, but it
always required copy-paste...

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From stefan at sun.ac.za  Fri May 25 01:46:53 2007
From: stefan at sun.ac.za (Stefan van der Walt)
Date: Fri, 25 May 2007 07:46:53 +0200
Subject: [IPython-dev] unit tests
Message-ID: <20070525054653.GS6192@mentat.za.net>

Hi all,

What is the preferred way of running the IPython unit tests?  In
runtests.py it says "ipython runtests.py" should work, but it throws
an exception here.

########################################################################
/home/stefan/lib/python2.5/site-packages/IPython/iplib.py in handle_normal(self, line_info)
   2110             line = ''
   2111 
-> 2112         self.log(line,line,continue_prompt)
   2113         return line
   2114 

<type 'exceptions.AttributeError'>: 'InteractiveShell' object has no attribute 'log'
########################################################################

Interestingly, when I run it using %run it actually works to some
extent, before it freezes:

########################################################################
In [2]: %run runtests.py
./test_prefilter.py
Out[3]: "\nTest which prefilter transformations get called for various input lines.\nNote that this does *not* test the transformations themselves -- it's just\nverifying that a particular combination of, e.g. config options and escape\nchars trigger the proper handle_X transform of the input line.\n\nUsage: run from the command line with *normal* python, not ipython:\n> python test_prefilter.py\n\nFairly quiet output by default.  Pass in -v to get everyone's favorite dots.\n"
------------------------------------------------------------
   File "<ipython console>", line 6
     IPython.Shell.start()
           ^
<type 'exceptions.SyntaxError'>: invalid syntax

./test_irunner.py
Out[13]: 'Test suite for the irunner module.\n\nNot the most elegant or fine-grained, but it does cover at least the bulk\nfunctionality.'
------------------------------------------------------------
   File "<ipython console>", line 42
     if __name__ == '__main__':
      ^
<type 'exceptions.SyntaxError'>: invalid syntax

./test_wildcard.py
------------------------------------------------------------
   File "<ipython console>", line 7
     root._apan=obj_t()
        ^
<type 'exceptions.SyntaxError'>: invalid syntax

./test_cd.ipy
/
/tmp
./test_ihist.ipy
Out[41]: 3
./test_shouldfail.ipy
/
./test_handlers.py
Out[46]: 'Test the various handlers which do the actual rewriting of the line.'
Out[0]: <IPython.Shell.IPShell instance at 0x8471fac>
------------------------------------------------------------
<type 'exceptions.IndentationError'>: expected an indented block (<ipython console>, line 3)

------> f2("a b c")
Out[0]: 'a b ca b c'
########################################################################

Thanks for any feedback.
St?fan


From stefan at sun.ac.za  Fri May 25 02:21:50 2007
From: stefan at sun.ac.za (Stefan van der Walt)
Date: Fri, 25 May 2007 08:21:50 +0200
Subject: [IPython-dev] What To Do With a Problem Like 'cd /'?
In-Reply-To: <46cb515a0705231153t6c3dd6e4y9a732067e2b83915@mail.gmail.com>
References: <2B5EDCAE-9C6C-481B-A51F-514780937B80@comcast.net>
	<46cb515a0705210100r7f0687f9udd561189b11ddfe4@mail.gmail.com>
	<5DC476FE-5D24-4353-A19F-2C0E131601A7@comcast.net>
	<46cb515a0705230946r7bee8a1bk3ff860f694393229@mail.gmail.com>
	<FF466FC0-45B6-4FC0-B904-75CA20E5053F@comcast.net>
	<46cb515a0705231153t6c3dd6e4y9a732067e2b83915@mail.gmail.com>
Message-ID: <20070525062150.GU6192@mentat.za.net>

On Wed, May 23, 2007 at 08:53:36PM +0200, Ville M. Vainio wrote:
> In the meantime, a handy alias to use for ipython devs:
> 
> $ alias timeline start http://projects.scipy.org/ipython/ipython/timeline
> $ %store timeline

Cute.  Under Linux systems you can use

alias timeline x-www-browser -n http://projects.scipy.org/ipython/ipython/timeline

Btw, you cannot use dashes (and other special chars) in alias-names,
but IPython allows it quite happily:

alias a-b 3

Cheers
St?fan


From hans_meine at gmx.net  Fri May 25 04:12:07 2007
From: hans_meine at gmx.net (Hans Meine)
Date: Fri, 25 May 2007 10:12:07 +0200
Subject: [IPython-dev] %history and %rep
In-Reply-To: <46cb515a0705241411s5a0a09dse5f96113496779c1@mail.gmail.com>
References: <46cb515a0705241153i4ed68c09u5639d09194ffbff@mail.gmail.com>
	<46cb515a0705241327h6e0ad1d1v6ba7943a861cd00@mail.gmail.com>
	<46cb515a0705241411s5a0a09dse5f96113496779c1@mail.gmail.com>
Message-ID: <200705251012.07746.hans_meine@gmx.net>

Am Donnerstag, 24. Mai 2007 23:11:34 schrieb Ville M. Vainio:
> %rep should use str(_) as the input line. I.e. the stringized version
> of the last result. Ever looked at those strings on variables that are
> so close yet so far, i.e. require you to do the productivity-killing
> chore of mouse-console-copypaste? Now you could do:
>
> $ l = ["hei", "vaan"]
>
> $ "".join(l)
>
> ==> heivaan
>
> $ rep
>
> $ heivaan_ <== cursor blinking
>
> I've often wanted to construct the input line and then edit it, but it
> always required copy-paste...

That is indeed a good idea (save the above rationale for the docs BTW).
I wonder whether %rep is a good name though.

Second, I want to say that your %rep 2 4 3:5 is a good idea, too - I very 
often define a macro "redo" only to repeat several steps at once.

Speaking of that - I often make the mistake that I pass comma-separated line 
numbers to %macro, e.g. "macro redo 4,5,7:10", which always throws "invalid 
literal for int()".  I would have provided a patch for extract_input_slices, 
but what do you think about that?  It could then also support "4,5,7-8".  Oh, 
it already supports "-" ranges, so I guess splitting on "," would not appear 
as a bad idea to anyone then?

Attached you'll find a small patch that does that, and also handles strange 
input like the latter examples:

%macro redo 4,5,7:10,15-16
%macro redo 4, 5, 7:10, 15-16
%macro redo 1,2 4 , 5, 7:10 15-16

Ciao, /  /
     /--/
    /  / ANS
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ipython-extract_input_slices.diff
Type: text/x-diff
Size: 449 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20070525/358fdaef/attachment.diff>

From hans_meine at gmx.net  Fri May 25 12:26:00 2007
From: hans_meine at gmx.net (Hans Meine)
Date: Fri, 25 May 2007 18:26:00 +0200
Subject: [IPython-dev] UNIX signal handling -> clean shutdown?
Message-ID: <200705251826.05234.hans_meine@gmx.net>

Hi!

I often leave an ipython console open in my office, and want to continue 
working later at home.  In such cases, I wish I could log in remotely and 
e.g. "kill -SIGUSR1" ipython in order to save the history cleanly.

Is that possible already?  Do you think it is a good idea?

-- 
Ciao, /  /                                                    .o.
     /--/                                                     ..o
    /  / ANS                                                  ooo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20070525/7bff55ac/attachment.sig>

From jng at europe.renre.com  Fri May 25 12:29:59 2007
From: jng at europe.renre.com (John Gill)
Date: Fri, 25 May 2007 17:29:59 +0100
Subject: [IPython-dev] UNIX signal handling -> clean shutdown?
In-Reply-To: <200705251826.05234.hans_meine@gmx.net>
References: <200705251826.05234.hans_meine@gmx.net>
Message-ID: <46570F07.6060308@europe.renre.com>

Have you come across screen?

If you run your ipython sessions within that you will be able to go home 
and reconnect to the same session.

John

Hans Meine wrote:
> Hi!
>
> I often leave an ipython console open in my office, and want to continue 
> working later at home.  In such cases, I wish I could log in remotely and 
> e.g. "kill -SIGUSR1" ipython in order to save the history cleanly.
>
> Is that possible already?  Do you think it is a good idea?
>
>  
*********************************************************************************** 
Renaissance Services of Europe Limited 
Company Reg. No. 393163 
Registered Office: 
1st Floor, Hardwicke House, Hatch Street, Dublin 2, Ireland. 
*********************************************************************************** 
Employees of Renaissance Services of Europe Limited  do not have the authority to bind contracts on behalf of Renaissance Reinsurance Limited (Bermuda), Renaissance Reinsurance of Europe, Davinci Re or Top Layer Re. 

This e-mail, including attachments, may contain information that is privileged, proprietary, non-public, confidential or exempt from disclosure and is intended to be conveyed only to the designated recipient(s). If you are not an intended recipient, please delete this email, including attachments, and do not disseminate, distribute or copy this communication, by email or otherwise. The unauthorized use, dissemination, distribution or reproduction of this email, including attachments, is prohibited and may be unlawful. We reserve the right to monitor and review the content of all messages sent to or from this e-mail address.

********************************************************************************* 



From vivainio at gmail.com  Fri May 25 13:03:23 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Fri, 25 May 2007 19:03:23 +0200
Subject: [IPython-dev] %history and %rep
In-Reply-To: <200705251012.07746.hans_meine@gmx.net>
References: <46cb515a0705241153i4ed68c09u5639d09194ffbff@mail.gmail.com>
	<46cb515a0705241327h6e0ad1d1v6ba7943a861cd00@mail.gmail.com>
	<46cb515a0705241411s5a0a09dse5f96113496779c1@mail.gmail.com>
	<200705251012.07746.hans_meine@gmx.net>
Message-ID: <46cb515a0705251003r3fb49aeds415c996146ef9207@mail.gmail.com>

On 5/25/07, Hans Meine <hans_meine at gmx.net> wrote:

> Attached you'll find a small patch that does that, and also handles strange
> input like the latter examples:
>
> %macro redo 4,5,7:10,15-16
> %macro redo 4, 5, 7:10, 15-16
> %macro redo 1,2 4 , 5, 7:10 15-16

I'm not really sure we *need* the support for ",", esp. as "new"
feature. 2:4 syntax is only there for people who got used to it, but
the current 1-3 7-8 syntax is as intuitive as it gets imo.

Just adjust your habits. :-)

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From vivainio at gmail.com  Fri May 25 13:55:05 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Fri, 25 May 2007 19:55:05 +0200
Subject: [IPython-dev] %rep implemented
Message-ID: <46cb515a0705251055h1e1913f5ya6243edec8203800@mail.gmail.com>

I implemented a (somewhat simpler than initially anticipated) version
of %rep in svn. It's in IPython.maghistory

Here's the docstring:

    r""" Repeat a command, or get command to input line for editing

    - %rep (no arguments):

    Place a string version of last input to the next input prompt. Allows you
    to create elaborate command lines without using copy-paste::

        $ l = ["hei", "vaan"]
        $ "".join(l)
        ==> heivaan
        $ %rep
        $ heivaan_ <== cursor blinking

    %rep 45

    Place history line 45 to next input prompt. Use %hist to find out
the number.

    %rep 1-4 6-7 3

    Repeat the specified lines immediately. Input slice syntax is the same as
    in %macro and %save.

    """

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From vivainio at gmail.com  Sat May 26 05:43:35 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Sat, 26 May 2007 11:43:35 +0200
Subject: [IPython-dev] Next-gen result printing using generics
Message-ID: <46cb515a0705260243y7d20fc18x187f909d45b73597@mail.gmail.com>

Simplegeneric rocks.

Coming soon to SVN, once I clean it up (remove deco syntax etc.):

------------

from IPython.generics import result_display

@result_display.when_type(LSString)
def print_lsstring(arg):
    print "LSString (.p, .n, .l, .s available). Value:"
    print arg


------------

In [4]: from IPython.genutils import *

In [5]: LSString("hello\nworld")
Out[5]: LSString (.p, .n, .l, .s available). Value:
hello
world

In [6]:


-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From vivainio at gmail.com  Sat May 26 05:46:05 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Sat, 26 May 2007 11:46:05 +0200
Subject: [IPython-dev] Next-gen result printing using generics
In-Reply-To: <46cb515a0705260243y7d20fc18x187f909d45b73597@mail.gmail.com>
References: <46cb515a0705260243y7d20fc18x187f909d45b73597@mail.gmail.com>
Message-ID: <46cb515a0705260246s341025b7l63ab7b0fab68c587@mail.gmail.com>

Forgot to add: I'm not deprecating the result_display hook. It's
executed right after the generic call, if the generic raises TryNext
(which the default generic does).

The hooks have the advantage of "chaining" through TryNext and I'm not
willing to lose that yet. The generic call is just the first loop in
the chain, which is convenient because they are the easiest to
implement.

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From vivainio at gmail.com  Sat May 26 06:26:10 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Sat, 26 May 2007 12:26:10 +0200
Subject: [IPython-dev] Next-gen result printing using generics
In-Reply-To: <46cb515a0705260243y7d20fc18x187f909d45b73597@mail.gmail.com>
References: <46cb515a0705260243y7d20fc18x187f909d45b73597@mail.gmail.com>
Message-ID: <46cb515a0705260326x3ae5c2acq2c639f5cd9beaac@mail.gmail.com>

On 5/26/07, Ville M. Vainio <vivainio at gmail.com> wrote:

> Coming soon to SVN, once I clean it up (remove deco syntax etc.):

Ok, it's in.

I also tried to untangle the mess of module interdependencies a little
bit; genutil.py is way too big.

"import IPython" now only imports a handful of modules automatically:

 ['ipapi','generics','ipstruct','Release','Shell']

This is also a kind of hint for the users about what modules they
might want to use in their own code.

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From walter at livinglogic.de  Sat May 26 06:38:12 2007
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Sat, 26 May 2007 12:38:12 +0200
Subject: [IPython-dev] Next-gen result printing using generics
In-Reply-To: <46cb515a0705260326x3ae5c2acq2c639f5cd9beaac@mail.gmail.com>
References: <46cb515a0705260243y7d20fc18x187f909d45b73597@mail.gmail.com>
	<46cb515a0705260326x3ae5c2acq2c639f5cd9beaac@mail.gmail.com>
Message-ID: <46580E14.2040709@livinglogic.de>

Ville M. Vainio wrote:
> On 5/26/07, Ville M. Vainio <vivainio at gmail.com> wrote:
> 
>> Coming soon to SVN, once I clean it up (remove deco syntax etc.):
> 
> Ok, it's in.

It looks like a double generic now. ;)

@generic
def result_display(result):
     """ print the result of computation """
     raise TryNext

result_display = generic(result_display)

Either the decorator or function call should go.

> [...]

Servus,
    Walter


From vivainio at gmail.com  Sat May 26 06:55:32 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Sat, 26 May 2007 12:55:32 +0200
Subject: [IPython-dev] Next-gen result printing using generics
In-Reply-To: <46580E14.2040709@livinglogic.de>
References: <46cb515a0705260243y7d20fc18x187f909d45b73597@mail.gmail.com>
	<46cb515a0705260326x3ae5c2acq2c639f5cd9beaac@mail.gmail.com>
	<46580E14.2040709@livinglogic.de>
Message-ID: <46cb515a0705260355w39d73e40hadb786e8d10451f5@mail.gmail.com>

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

> Either the decorator or function call should go.

Argh, of course. I was a bit careless with the "decorator removal", to
the extent that I forgot the... decorator removal.

BTW, you could change the ipipe to use this generic as well.

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From walter at livinglogic.de  Sat May 26 07:18:50 2007
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Sat, 26 May 2007 13:18:50 +0200
Subject: [IPython-dev] Next-gen result printing using generics
In-Reply-To: <46cb515a0705260355w39d73e40hadb786e8d10451f5@mail.gmail.com>
References: <46cb515a0705260243y7d20fc18x187f909d45b73597@mail.gmail.com>	
	<46cb515a0705260326x3ae5c2acq2c639f5cd9beaac@mail.gmail.com>	
	<46580E14.2040709@livinglogic.de>
	<46cb515a0705260355w39d73e40hadb786e8d10451f5@mail.gmail.com>
Message-ID: <4658179A.8050403@livinglogic.de>

Ville M. Vainio wrote:
> On 5/26/07, Walter D?rwald <walter at livinglogic.de> wrote:
> 
>> Either the decorator or function call should go.
> 
> Argh, of course. I was a bit careless with the "decorator removal", to
> the extent that I forgot the... decorator removal.
> 
> BTW, you could change the ipipe to use this generic as well.

That was going through my head too. However the current display hook 
fires for subclasses of Table too (that's why you can type ils instead 
of ils()). For this to work, we'd need a when_subclass() decorator in 
simplegeneric.

Servus,
    Walter


From vivainio at gmail.com  Sat May 26 08:21:34 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Sat, 26 May 2007 14:21:34 +0200
Subject: [IPython-dev] Next-gen result printing using generics
In-Reply-To: <4658179A.8050403@livinglogic.de>
References: <46cb515a0705260243y7d20fc18x187f909d45b73597@mail.gmail.com>
	<46cb515a0705260326x3ae5c2acq2c639f5cd9beaac@mail.gmail.com>
	<46580E14.2040709@livinglogic.de>
	<46cb515a0705260355w39d73e40hadb786e8d10451f5@mail.gmail.com>
	<4658179A.8050403@livinglogic.de>
Message-ID: <46cb515a0705260521l28c23c4bx26e2591d6917c778@mail.gmail.com>

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

> That was going through my head too. However the current display hook
> fires for subclasses of Table too (that's why you can type ils instead
> of ils()). For this to work, we'd need a when_subclass() decorator in
> simplegeneric.

Doesn't when_type do this?

I see the MRO mentioned in the sources anyway...

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From walter at livinglogic.de  Sat May 26 08:34:59 2007
From: walter at livinglogic.de (=?ISO-8859-1?Q?Walter_D=F6rwald?=)
Date: Sat, 26 May 2007 14:34:59 +0200
Subject: [IPython-dev] Next-gen result printing using generics
In-Reply-To: <46cb515a0705260521l28c23c4bx26e2591d6917c778@mail.gmail.com>
References: <46cb515a0705260243y7d20fc18x187f909d45b73597@mail.gmail.com>	
	<46cb515a0705260326x3ae5c2acq2c639f5cd9beaac@mail.gmail.com>	
	<46580E14.2040709@livinglogic.de>	
	<46cb515a0705260355w39d73e40hadb786e8d10451f5@mail.gmail.com>	
	<4658179A.8050403@livinglogic.de>
	<46cb515a0705260521l28c23c4bx26e2591d6917c778@mail.gmail.com>
Message-ID: <46582973.1020705@livinglogic.de>

Ville M. Vainio wrote:
> On 5/26/07, Walter D?rwald <walter at livinglogic.de> wrote:
> 
>> That was going through my head too. However the current display hook
>> fires for subclasses of Table too (that's why you can type ils instead
>> of ils()). For this to work, we'd need a when_subclass() decorator in
>> simplegeneric.
> 
> Doesn't when_type do this?

No, it checks the class of the argument not the argument itself:

In [1]: from simplegeneric import *
In [2]: @generic
    ...: def foo(x):
    ...:     print x
    ...:
    ...:
In [3]: @foo.when_type(int)
    ...: def foo_int(x):
    ...:     print "int", x
    ...:
    ...:
In [4]: foo(42)
int 42
In [5]: foo(int)
<type 'int'>

> I see the MRO mentioned in the sources anyway...

Yes, but it iterates the MRO of the class of the argument to find an 
implementation, so passing the class will iterate the MRO of type (or 
types.ClassType for old-style classes).

Servus,
    Walter




From jorgen.stenarson at bostream.nu  Tue May 29 14:18:18 2007
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Tue, 29 May 2007 20:18:18 +0200
Subject: [IPython-dev] using magic_cd when on a network share gives error
	message
Message-ID: <465C6E6A.7020205@bostream.nu>

On windows using magic_cd when current directory is on a network share 
gives an error message complaining about not being able to launch 
cmd.exe on a network share.

I tracked down the problem to the set_title command which makes a system
call via os.system.

I have attached a patch that just change directory to c: temporarily. 
There is also an example implementation using ctypes included that does
not need this workaround.

/J?rgen


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/applefile
Size: 1492 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20070529/3e11a0af/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: set_title_patch.diff
Type: application/octet-stream
Size: 801 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20070529/3e11a0af/attachment.obj>

From jorgen.stenarson at bostream.nu  Tue May 29 14:23:40 2007
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Tue, 29 May 2007 20:23:40 +0200
Subject: [IPython-dev] New pyreadline installer
Message-ID: <465C6FAC.5000905@bostream.nu>

There has not been any new issues reported on pyreadline for a while. 
Perhaps it is time to try a new release, can you do that Fernando?

Starting saturday I will be gone to a conference and some vacation for 
about two weeks. I will not be available for that time.

/J?rgen



From ondrej.marsalek at matfyz.cz  Tue May 29 14:47:51 2007
From: ondrej.marsalek at matfyz.cz (Ondrej Marsalek)
Date: Tue, 29 May 2007 20:47:51 +0200
Subject: [IPython-dev] ipython1 and mpi
Message-ID: <97b6a4330705291147p4fdb17adu503759f4ec45ce@mail.gmail.com>

hi,

i would like to test ipython1 together with mpi and one thing is a bit
confusing for me. the faq says:

"In fact, IPython Engines can be started as MPI processes (they can
call MPI_Init) and you can then use MPI however you want."

does that mean that it is my option to call mpi_init by hand or does
it somehow happen behind the scenes? i understand that i have to use
mpirun to launch the engines.

i would like to use mpi from within an extension wrapped using swig
but i suppose that this is not a problem.

regards,
ondrej


From vivainio at gmail.com  Tue May 29 15:00:34 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 29 May 2007 21:00:34 +0200
Subject: [IPython-dev] using magic_cd when on a network share gives
	error message
In-Reply-To: <465C6E6A.7020205@bostream.nu>
References: <465C6E6A.7020205@bostream.nu>
Message-ID: <46cb515a0705291200o4b46809cpe0e6bd6197bca451@mail.gmail.com>

On 5/29/07, J?rgen Stenarson <jorgen.stenarson at bostream.nu> wrote:

> I have attached a patch that just change directory to c: temporarily.
> There is also an example implementation using ctypes included that does
> not need this workaround.

Can you alter the patch so that the ctypes approach is the default
set_term_title, with the "title" command based implementation being
only a secondary fallback?

Or better yet, just check it into svn yourself.

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From vivainio at gmail.com  Tue May 29 15:04:24 2007
From: vivainio at gmail.com (Ville M. Vainio)
Date: Tue, 29 May 2007 21:04:24 +0200
Subject: [IPython-dev] New pyreadline installer
In-Reply-To: <465C6FAC.5000905@bostream.nu>
References: <465C6FAC.5000905@bostream.nu>
Message-ID: <46cb515a0705291204u906ec21w710f75ecf24ef72e@mail.gmail.com>

On 5/29/07, J?rgen Stenarson <jorgen.stenarson at bostream.nu> wrote:

> There has not been any new issues reported on pyreadline for a while.
> Perhaps it is time to try a new release, can you do that Fernando?

The sooner the better. Just make it so that fernando can just upload
it to the ftp, i.e. create the maintenance branch in SVN etc.

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


From jorgen.stenarson at bostream.nu  Tue May 29 17:32:40 2007
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Tue, 29 May 2007 23:32:40 +0200
Subject: [IPython-dev] using magic_cd when on a network share gives
 error message
In-Reply-To: <46cb515a0705291200o4b46809cpe0e6bd6197bca451@mail.gmail.com>
References: <465C6E6A.7020205@bostream.nu>
	<46cb515a0705291200o4b46809cpe0e6bd6197bca451@mail.gmail.com>
Message-ID: <465C9BF8.3050109@bostream.nu>

Ville M. Vainio skrev:
> On 5/29/07, J?rgen Stenarson <jorgen.stenarson at bostream.nu> wrote:
> 
>> I have attached a patch that just change directory to c: temporarily.
>> There is also an example implementation using ctypes included that does
>> not need this workaround.
> 
> Can you alter the patch so that the ctypes approach is the default
> set_term_title, with the "title" command based implementation being
> only a secondary fallback?
> 
> Or better yet, just check it into svn yourself.
> 
Done

/J?rgen


From jorgen.stenarson at bostream.nu  Tue May 29 17:33:51 2007
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Tue, 29 May 2007 23:33:51 +0200
Subject: [IPython-dev] New pyreadline installer
In-Reply-To: <46cb515a0705291204u906ec21w710f75ecf24ef72e@mail.gmail.com>
References: <465C6FAC.5000905@bostream.nu>
	<46cb515a0705291204u906ec21w710f75ecf24ef72e@mail.gmail.com>
Message-ID: <465C9C3F.90001@bostream.nu>

Ville M. Vainio skrev:
> On 5/29/07, J?rgen Stenarson <jorgen.stenarson at bostream.nu> wrote:
> 
>> There has not been any new issues reported on pyreadline for a while.
>> Perhaps it is time to try a new release, can you do that Fernando?
> 
> The sooner the better. Just make it so that fernando can just upload
> it to the ftp, i.e. create the maintenance branch in SVN etc.
> 
I have updated release.py to show version number 1.4.4 and I have 
created a maintenance branch.

/J?rgen


From fperez.net at gmail.com  Tue May 29 18:13:02 2007
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 29 May 2007 16:13:02 -0600
Subject: [IPython-dev] New pyreadline installer
In-Reply-To: <465C9C3F.90001@bostream.nu>
References: <465C6FAC.5000905@bostream.nu>
	<46cb515a0705291204u906ec21w710f75ecf24ef72e@mail.gmail.com>
	<465C9C3F.90001@bostream.nu>
Message-ID: <db6b5ecc0705291513s4e550f5arec37899826e6a6bd@mail.gmail.com>

On 5/29/07, J?rgen Stenarson <jorgen.stenarson at bostream.nu> wrote:
> Ville M. Vainio skrev:
> > On 5/29/07, J?rgen Stenarson <jorgen.stenarson at bostream.nu> wrote:
> >
> >> There has not been any new issues reported on pyreadline for a while.
> >> Perhaps it is time to try a new release, can you do that Fernando?
> >
> > The sooner the better. Just make it so that fernando can just upload
> > it to the ftp, i.e. create the maintenance branch in SVN etc.
> >
> I have updated release.py to show version number 1.4.4 and I have
> created a maintenance branch.

Done at:

http://ipython.scipy.org/dist/

I'm super busy so I've been mostly silent on list, but I don't want to
stall this.  Let me know of any needed changes.

Cheers,

f


From danmil at comcast.net  Wed May 30 10:18:51 2007
From: danmil at comcast.net (Dan Milstein)
Date: Wed, 30 May 2007 10:18:51 -0400
Subject: [IPython-dev] Regression bug in 0.8.x input filtering
In-Reply-To: <200705241650.53129.hans_meine@gmx.net>
References: <200705181242.22310.hans_meine@gmx.net>
	<db6b5ecc0705232323ydd8eb8cgbce7ed4d12815db9@mail.gmail.com>
	<15785272-E89E-48EA-A022-969EF465D9EB@comcast.net>
	<200705241650.53129.hans_meine@gmx.net>
Message-ID: <67D66398-613C-4448-BA7B-7FE3A71EF6D7@comcast.net>

Okay, I think I've fixed this (just committed it to svn).

Now, as per the requests below, any magics, aliases or autocalls must  
be separated from the 'rest' of the line by a whitespace for ipython  
to treat them special.

Thus, e.g.

  $ r'a_string'

Will no longer trigger the %r magic even if automagic is on.  Added  
tests to verify this.

I'm hopeful that this isn't going to screw anything else up, but  
everything prefiltering related is complex, so lemme know if it blows  
things up interestingly.

-D


On May 24, 2007, at 10:50 AM, Hans Meine wrote:

> On Donnerstag 24 Mai 2007, Dan Milstein wrote:
>> Okay, I'm sold on the %r as a reasonable magic, and whitespace
>> splitting as a reasonable req.
> I too think that whitespace splitting is reasonable, but I would  
> never use %r.
> OTOH, I see that every ipython user has his/her own habits.
>
>> Specifically, we jump through some hoops right now so that:
>>> !thing?
>>
>> and
>>
>>> !!thing?
>>
>> Trigger the shell handler, and *not* the help handler.  This was
>> particularly important/useful because the qmark is a part of some
>> valid shell commands.
> Part of globs in particular.  globs are not evaluated by the shell  
> in the
> first (command) word, so I would suggest..
>> maybe it's okay if !thing? triggers help, as long as:
>>> !thing (.*)?
>>
>> and
>>
>>> !!thing (.*)?
> exactly this.
>
> -- 
> Ciao, /  /                                                    .o.
>      /--/                                                     ..o
>     /  / ANS                                                  ooo
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev



From jorgen.stenarson at bostream.nu  Wed May 30 13:01:03 2007
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Wed, 30 May 2007 19:01:03 +0200
Subject: [IPython-dev] New pyreadline installer
In-Reply-To: <db6b5ecc0705291513s4e550f5arec37899826e6a6bd@mail.gmail.com>
References: <465C6FAC.5000905@bostream.nu>	
	<46cb515a0705291204u906ec21w710f75ecf24ef72e@mail.gmail.com>	
	<465C9C3F.90001@bostream.nu>
	<db6b5ecc0705291513s4e550f5arec37899826e6a6bd@mail.gmail.com>
Message-ID: <465DADCF.8080203@bostream.nu>

Fernando Perez skrev:
> On 5/29/07, J?rgen Stenarson <jorgen.stenarson at bostream.nu> wrote:
>> Ville M. Vainio skrev:
>> > On 5/29/07, J?rgen Stenarson <jorgen.stenarson at bostream.nu> wrote:
>> >
>> >> There has not been any new issues reported on pyreadline for a while.
>> >> Perhaps it is time to try a new release, can you do that Fernando?
>> >
>> > The sooner the better. Just make it so that fernando can just upload
>> > it to the ftp, i.e. create the maintenance branch in SVN etc.
>> >
>> I have updated release.py to show version number 1.4.4 and I have
>> created a maintenance branch.
> 
> Done at:
> 
> http://ipython.scipy.org/dist/
> 
> I'm super busy so I've been mostly silent on list, but I don't want to
> stall this.  Let me know of any needed changes.
> 
> Cheers,
> 
> f
> 
Great!  It installed ok for me.

/J?rgen


From jorgen.stenarson at bostream.nu  Wed May 30 13:06:10 2007
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Wed, 30 May 2007 19:06:10 +0200
Subject: [IPython-dev] What should be done for pyreadline 1.5?
Message-ID: <465DAF02.2020402@bostream.nu>

I have created a milestone for pyreadline 1.5 in Trac. So if you have 
suggestions for what should be done feel free to add enhancement 
requests/tickets attached to that milestone.

I have added two myself:
#166 page up/page down  should scroll a full window and be rebindable
#167 pyreadline callback interface requested by Stefan Rank for twisted 
integration

I will start work on this when I return from my conference/vacation in 
two weeks.

/J?rgen



From ellisonbg.net at gmail.com  Wed May 30 15:37:51 2007
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 30 May 2007 13:37:51 -0600
Subject: [IPython-dev] ipython1 and mpi
In-Reply-To: <97b6a4330705291147p4fdb17adu503759f4ec45ce@mail.gmail.com>
References: <97b6a4330705291147p4fdb17adu503759f4ec45ce@mail.gmail.com>
Message-ID: <6ce0ac130705301237g45feccc9ha8a33d9d61d75c9d@mail.gmail.com>

Ondrej,

Here is a broad picture of how mpi integration works:

1) When the engines start, the look for a configuration variable
called mpiImportStatement.  If it is set, that strings gets exec'd the
first thing when the engine starts.  This statement should be a python
statement that causes mpi_init to be called.  A typically example is:

mpiImportStatement = "from mpi4py import MPI as mpi"

The docstrings for mpiImportStatement are here:

http://projects.scipy.org/ipython/ipython/browser/ipython/branches/saw/ipython1/config/objects.py

To set this variable, use the file mpirc.py as a template and drop it
into your ~/.ipython directory.

> does that mean that it is my option to call mpi_init by hand or does
> it somehow happen behind the scenes? i understand that i have to use
> mpirun to launch the engines.

2) Then you must start the engines using

To use mpi from within swig wrapped code there are a few things you
will have to figure out:

1) Does that wrapped code call mpi_init, or does it expect that
mpi_init has already been called?

2) Which mpi implementation are you using?  With a modern mpi
implementation like openmpi, things are fairly easy.  If you are using
an older version like mpich1, like becomes much more complicated
because of how mpich starts processes.  I can show you how to get that
going if you need to.

Here is how I would go about things:

* Use openmpi and install the mpi4py python bindings to mpi

* Set the mpiImportStatement to import mpi4py.  This will cause
mpi_init to be called.

* Make sure that your wrapped code doesn't call mpi_init again.

With that, things should just work.  Let me know how this goes - I
realize all of this is still somewhat complicated.

Brian


>
> regards,
> ondrej
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>