[IPython-dev] [IPython-user] IPython 0.8.2 and PyReadline 1.5, getting ready for release...

Fernando Perez fperez.net at gmail.com
Sun Nov 25 14:32:40 EST 2007


On Nov 24, 2007 11:51 PM, wang frank <fw3 at hotmail.co.jp> wrote:
>
>  Just curious. Has anyone tested this release with xemacs 21.4.21 and emacs
> 22.1 in linux and window XP? I assume that it works out of box in linux.
> However, it will really help normal user if some details on how to make it
> work in window with xemacs and emacs.

Actually, under gutsy emacs22 has problems loading python-mode at all,
so I can't easily test it.  There are fixes for the issue (it was
discussed at length on the numpy list) but I'm using an outside
emacs23 snapshot so I can get proper XFT font support, so I don't
really care (and can't spend time on it).

I used to be an XEmacs guy and had used this on and off without any
problems, but I haven't used XEmacs for a few months (since I switched
to CVS emacs for the font support).  Now I just noticed that while
XEmacs seems to load ipython just fine, it won't connect to the X
server for matplotlib use (my default mode loads ipython -pylab).  I
have no idea why emacs is OK with X11 but not XEmacs, I'd never seen
the error before.

It would be *really nice* if our emacs/windows users could collect the
wisdom on how to make it correctly work in that platform, and post it
on the wiki.  The cookbook would be a good place for this:

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

Note that for now, I've re-enabled wiki account creation in case
anyone wants to pitch in.  The message on the page still says that
it's disabled, but it's not :)  I'll turn it off again when the next
wave of spammers comes, perhaps for now the message will distract a
few of these cockroaches.  But if any of you is willing to help on the
wiki with the emacs info, you should be able to make an account right
away.

>  One more question. Ipython is much better than the shell comes with python
> release. Why does python includes the ipython in it release?

ipython is too big and too complex for realistic inclusion in the
standard library, I think.  I've never tried to lobby for its
inclusion because I doubt they'd go for it, but feel free to ask them.
 I should add that if I were Guido, I'd probably say no :) (the
reasons being that I wouldn't want such a large maintenance burden
inside the core code just for the interactive usage cases).

Cheers,

f



More information about the IPython-dev mailing list