At 02:45 PM 8/27/03 -0700, Guido van Rossum wrote:
I've been working on a set of Python tools that use readline, but want to keep history separate between different interaction modes. Unfortunately, this really needs to be able to access readline's clear_history(), as read_history_file() leaves existing history intact.
Sounds like a good feature.
I'd be happy to whip up a patch to add this (as readline.clear_history()), but I was wondering if perhaps the reason it's not currently exported by the readline module is a compatibility issue for older readline implementations that are officially supported. Thanks.
It's probably laziness. When I created the initial readline module, I didn't know anything about the C API of GNU readline. All I wanted was basic readline functionality, and I applied the YAGNI principle vigorously. Gradually, various people have added APIs for various useful GNU readline APIs.
But there might be a version issue as well. I have various versions of the readline sources online just for this purpose (GNU readline is notorious for not providing an easy way to check at compile-time which version you are using), and I note that clear_history() is present in 2.2, but not in 2.0. I seem to recall that 2.2 is the oldest widely used version, so I think you're safe.
Hmmm... the CVS log for Modules/readline.c makes mention of changes made to assure backward compatibility with readline 2.1 and 2.0, and #ifdefs some items as a result. I suppose I could wrap a clear_history in the same. However, that leads to a couple of questions:
* Should clear_history() only appear in the readline module if the facility exists?
* If it should always appear, should it be a no-op if the facility isn't available, or raise an error?
"Errors should never pass silently" suggests that if it does appear, it should raise an error if the facility doesn't exist. So, I guess the question is, should you get an error trying to access clear_history(), or an error calling it? (And in the latter case, is NotImplementedError the right thing to raise?)
Last question (I hope): as a feature, I presume this has to wait for 2.4 to get in, yes?