[IPython-user] readline update
Thu Nov 19 09:41:23 CST 2009
Thanks! Build failure on Karmic, though:
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall
-Wstrict-prototypes -fPIC -DHAVE_RL_COMPLETION_MATCHES
-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
* Safely decref `op` and set `op` to NULL, especially useful in
* and tp_dealloc implementatons.
* Note that "the obvious" code can be deadly:
* 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
* down. This has in fact been a rich historic source of miserable
* hard-to-diagnose) segfaulting (and other) bugs.
* The safe way is:
* 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
* to use Py_CLEAR() even if you can't think of a reason for why you
(Should I submit a Python bug for the typo of "implementatons" in that
On Thu, Nov 19, 2009 at 9:35 AM, Ludwig Schwardt
> 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
> - 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!
> IPython-user mailing list
More information about the IPython-user