[Python-Dev] a readline replacement?

Michael Hudson mwh21@cam.ac.uk
14 Jan 2001 00:41:35 +0000

Michael Hudson <mwh21@cam.ac.uk> writes:

> It wouldn't be particularly hard to rewrite editline in Python (we
> have termios & the terminal handling functions in curses - and even
> ioctl if we get really keen).
> I've been hacking on my own Python line reader on and off for a while;
> it's still pretty buggy, but if you're feeling brave you could look at:
> http://www-jcsu.jesus.cam.ac.uk/~mwh21/hacks/pyrl-0.0.0.tar.gz

As I secretly planned <wink>, the embarrassment of having code that
full of holes publicly accessible spurred me to writing a much better
version, to be found at:


(or, now rsync works there again, in the equivalent place on the

If you unpack it and execute

$ python python_reader.py

you should get something that closely mimics the current interpreter
top level.  It supports a wide range of cursor motion commands,
built-in support for multiple line input and history (including
incremental search).  It doesn't do completion, basically because I
haven't got round to it yet, and it will get into severe trouble if
you enter an input that is taller than your terminal (I think this
should be surmountable, but I haven't gotten round to this either).
Another thing that I haven't gotten round to yet is documentation.
After I've tackled these points I'll probably stick it up on

I've been using it as my standard python shell for a week or so, and
quite like it, though the lack of completion is a drag.

It is probably staggeringly unportable, so I'd appreciate finding out
how it breaks on systems other that Linux with terminals other than

Have the changes to enable use of editline been checked in yet?  I
worry that the licensing situation around the readline module is grey
at best...


  That's why the smartest companies use Common Lisp, but lie about it
  so all their competitors think Lisp is slow and C++ is fast.  (This
  rumor has, however, gotten a little out of hand. :)
                                        -- Erik Naggum, comp.lang.lisp