[IPython-user] readline update

Kenneth Arnold kenneth.arnold@gmail....
Thu Nov 19 09:41:23 CST 2009

Thanks! Build failure on Karmic, though:

gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-DHAVE_RL_CATCH_SIGNAL -I. -I/usr/include/python2.6 -c
Modules/readline.c -o build/temp.linux-x86_64-2.6/Modules/readline.o
Modules/readline.c: In function ‘on_completion_display_matches_hook’:
Modules/readline.c:697: error: expected ‘;’ before ‘,’ token
Modules/readline.c:703: error: expected ‘;’ before ‘,’ token

In fact, tracing that leads to Python's object.h, which has a warning
that's probably worth a read for anyone writing code against the
CPython API:

* Safely decref `op` and set `op` to NULL, especially useful in
 * and tp_dealloc implementatons.
 * Note that "the obvious" code can be deadly:
 *     Py_XDECREF(op);
 *     op = NULL;
 * Typically, `op` is something like self->containee, and `self` is
 * using its `containee` member.  In the code sequence above, suppose
 * `containee` is non-NULL with a refcount of 1.  Its refcount falls
 * 0 on the first line, which can trigger an arbitrary amount of code,
 * possibly including finalizers (like __del__ methods or weakref
 * coded in Python, which in turn can release the GIL and allow other
 * to run, etc.  Such code may even invoke methods of `self` again, or
 * cyclic gc to trigger, but-- oops! --self->containee still points to
 * object being torn down, and it may be in an insane state while
being torn
 * down.  This has in fact been a rich historic source of miserable
(rare &
 * hard-to-diagnose) segfaulting (and other) bugs.
 * The safe way is:
 *      Py_CLEAR(op);
 * That arranges to set `op` to NULL _before_ decref'ing, so that any
 * triggered as a side-effect of `op` getting torn down no longer
 * `op` points to a valid object.
 * There are cases where it's safe to use the naive code, but they're
 * For example, if `op` points to a Python integer, you know that
 * one of those can't cause problems -- but in part that relies on
 * Python integers aren't currently weakly referencable.  Best
practice is
 * to use Py_CLEAR() even if you can't think of a reason for why you
need to.

(Should I submit a Python bug for the typo of "implementatons" in that
text? <grin>)


On Thu, Nov 19, 2009 at 9:35 AM, Ludwig Schwardt
<ludwig.schwardt@gmail.com> wrote:
> Some good news about readline for a change...
> I've finally updated the Python readline package on PyPI
> (http://pypi.python.org/pypi/readline/) to version 2.6.1. The
> highlights:
> - An egg for the default system Python 2.6.1 on Snow Leopard (the fact
> that I had a shiny new iMac on my desk inspired this update :-)).
> - An egg for the default system Python 2.5.1 on Leopard.
> - The source package finally builds automatically if you don't have
> one of the above systems (thanks, Sridhar!). I've tested it with
> Python 2.5 on Tiger, which works. It should also work on Linux systems
> now (removed the Mac-specific flags in this case).
> - Based on readline 6.0.
> - Backported a bugfix from Python trunk which removes the "spurious
> trailing space" bug mentioned in the bug reports below:
>  * https://bugs.launchpad.net/python/+bug/470824
>  * http://bugs.python.org/issue5833
>  * http://trac.sagemath.org/sage_trac/ticket/2469
> The last point makes this package useful on Ubuntu Karmic too, which
> shipped with libreadline 6.0 and Python versions without the bugfix.
> Getting a working readline in IPython on the Mac should therefore be
> as easy as "sudo easy_install readline". Please test and let me know
> of any problems!
> Ludwig
> _______________________________________________
> IPython-user mailing list
> IPython-user@scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-user

More information about the IPython-user mailing list