[IPython-dev] Frontend: curses or urwid?

[Fernando Perez]

Hi Wendell,

It's best to keep replies on-list so we get feedback from everyone, so
I've put the  list back in the reply, keeping your context in full.

On Tue, Mar 23, 2010 at 5:40 AM, Wendell Smith <wackywendell at gmail.com> wrote:
> To respond to your points - urwid looks quite actively maintained, although
> possibly short on manpower. In the last month, there have been commits from
> 3 or 4 different people every couple days, and the last two versions came
> out on Jan 25 (0.9.9.1) and Nov 15 (0.9.9). They are, however, rather late
> in hitting their milestones (4-5 months or so), and python 3 compatibility
> is not listed as a goal.

OK, thanks for that info. It's not like in ipython we've been stellar
about milestones :)  Python3 is an issue, because eventually we will
want to move there, and the more dependencies we have stuck on 2.x,
the harder that makes life.  One reason we're so excited about zmq is
because Twisted is looking very slow to move to 3.x, while the zmq
bindings can be generated for py3 *today* (since Cython is 3.x-savvy).
 So if we can completely move off twisted, we'd have one more thing on
3.x.

And that is an argument for going with curses: being part of the
standard library has several benefits, the most obvious is that  it's
installed already with any python (on posix), and the other is that
the 3.x maintenance is done for us.


> As for easy_install - that's how I got it. It worked fine for me (Ubuntu
> 9.10). As for other platforms, curses is incompatible with windows, and the
> pypi page claims it runs on anything posix, including macs.
>
> I've already created extremely limited prototypes in both curses and urwid -
> more as a learning exercise than anything else, and the code for both is
> hideous. I think I'll take your suggestion and start working on more serious
> prototypes.

Ok, sounds good.  Choosing supporting libraries is always a tricky
game: the stdlib is my first choice when possible, for the reasons
stated above.  But sometimes the advantages of a third-party tool are
significant enough to warrant its use.  It's a judgment call that must
be made on a case by case basis. The way I think of it, the non-stdlib
tool must prove it's 'better enough' than whatever is in the stdlib to
use it, *unless* it's tiny enough (single-file, more or less) that we
can ship a copy in ipython.externals.  But that's a practice we should
reserve to  special cases that are really very small.

If you get prototypes working, do put them in a branch that everyone
can play with, it will be easier to give you feedback that way.

>
> As for the zmq frontend kernel - great! I'm having trouble getting it to
> work, but that could be my fault - getting zmq installed, pyzmq installed,
> and then the example was a bit much. But I don't need it that much right
> now, anyway. Hopefully, zmq will be easier to install soon, right?

Well, the install didn't have any problems for me, but I did have
Brian next to me telling me what to do :)  I'll  post a separate
message about the zmq stuff, and I'll include instructions that should
help.

> Anyways, I'll get back to coding!

Sounds good :)

Cheers,

f