This post originated from an RSS feed registered with Python Buzz
by Ben Last.
Original Post: On The Reading Of Lines
Feed Title: The Law Of Unintended Consequences
Feed URL: http://benlast.livejournal.com/data/rss
Feed Description: The Law Of Unintended Consequences
A selection of readline modules, their proliferation, care and feeding.
When I typed the title of this entry, it kept emerging from my fingers as "The Readling Of Linels"; how wonderfully Stanley Unwin. Which has nothing much to do with anything, but I like it.
Those of us who try to write shells, or other command-line-oriented stuff, eventually come up against the world of confusion that is cunningly hidden behind the simple statement:
import readline
If you're in the happy situation of running code on only one machine, or one platform whose configuration you control utterly, then that may be all you need; a fully functional readline implementation may spring into being, installing itself as the handler for any calls to sys.stdin.readline() and providing you with hours of error-free input, history recall and what not. Or, if you're not so fortunate, it may not. This will probably matter to you whether you're writing console-based Python or not - the Python interpreter itself loads readline at startup to provide line-editing functionality.
Most (if not all) Unix-based python installations will have a readline that wraps the GNU readline library or some equivalent thereof. This is the model for readline functionality against which other implementations are measured. It's not perfect from a Python point of view (for example, the command history content is available only via get_history_item() and get_current_history_length()), but since it's essentially a C library wrapped up, such things can be forgiven.
On Windows, the situation's much more variable. Those of us who use cygwin and run Python from a bash prompt get an equivalent readline built in, assuming we use the python environment that comes with cygwin, but run another Python distribution, such as Enthought's or ActiveState's, especially under the Windows CMD shell, and you're back with very basic line functionality. There are at least two alternative readlines that you can install. Chris Gonnerman's Python Alternative Readline falls short of the GNU benchmark in a couple of significant respects. For instance, it has minimal history handling - there's no way to access the actual history list other than by referencing readline.history directly (which is not especially safe) and the history file is read at module import time. It provides a number of the "standard" methods, such as set_completer, parse_and_bind, etc., but they're all stubs (all they do is pass). This is somewhat less than useless, since one can't even detect whether the module has the actual functionality without inspecting the source.
Gary Bishop's equivalent from the UNC Python Tools project is considerably more functional. It requires Thomas Heller's ctypes to work, making installation not quite as simple as drop-into-site-packages, but it's well worth it. It has an almost complete set of equivalents to the GNU module but scores highly by providing a large number of extended methods (as attributes of a Readline class) and adding intelligence to the others. For instance, the add_history is smart enough not to add a duplicate entry to the end of the existing list. The best feature, in my humble and problem-oriented opinion, is that the readline.Readline class is easy to subclass, for example to re-enable tab functionality (by default "tab" is the command-completion character, and if you're used to using it for indent, losing it can drive you mad). In fact, with this module, readline support is arguably better on Windows than on Linux (heresy!). The ability to subclass the behaviour of readline is a real advantage; allowing extra functions to be added by defining methods and binding them at runtime using parse_and_bind.
The problem with there being several different ways to address the same problem is that those of us attempting to write portable code have to try and deal with them all. Thus Quasi has to attempt to detect what subset of all readline functionality is available and work around it where it isn't. Of course, the obvious solution to that is to write yet another readline that interoperates with all the existing ones... and if I had time for that I'd be a happier person than I am now :) Anyway, should you know of any implementations I've missed, or find fault with the way Quasi uses readline (hint; try the history and recall commands), please let me know.
Previous Topic
