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. --Guido van Rossum (home page: http://www.python.org/~guido/)

...

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.

That's always better, of course. How old were those log entries?

However, that leads to a couple of questions:

* Should clear_history() only appear in the readline module if the facility exists?

Yes.

* If it should always appear, should it be a no-op if the facility isn't available, or raise an error?

N/A.

"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?)

I like it if the function is not available at all when it's not implemented. When you naively try to use it, the behavior is pretty much the same: you get an exception. But a program that wants to do soemthing different if the feature exists can test for presence of the attribute, and that's always better than having to call it and see if it raises NotImplementedError. NotImplementedError is mostly for abstract base classes. An extra advantage is that by testing for presence of the feature, you can cope with older Python versions is the same way as you cope with ancient readline versions.

Last question (I hope): as a feature, I presume this has to wait for 2.4 to get in, yes?

Probably. I'm personally not so stringent for minor stuff like this (hey, I added bool() to 2.2.1 :-), but it seems others are increasingly resisting even minor feature additions in micro releases (except in the email package :-). --Guido van Rossum (home page: http://www.python.org/~guido/)

At 06:18 PM 8/27/03 -0400, Barry Warsaw wrote:

...

Last question (I hope): as a feature, I presume this has to wait for 2.4 to get in, yes?

Hmm, it won't break backward compatibility, so maybe 2.3.1 would be okay. OTOH, it ain't a bug fix. OTOOH, 2.4 is a loonnngg way away.

As a practical matter, I'll initially be writing this as a patch against 2.2, which is where I actually need it. :) But I'll port it to be against 2.3 before I submit it. Hmmm... that makes me think of tests... I guess I won't really be able to supply a test for the feature, since that would just be testing whether the feature is available.

At 03:13 PM 8/27/03 -0700, Guido van Rossum wrote:

...

...

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.

That's always better, of course. How old were those log entries?

Last December there's a checkin by you of a patch from Magnus Lie Hetland to support 2.0/2.1, on the Python 2.3 branch. More recently, this support was backported to the Python 2.2 maintenance branch, and released in 2.2.3. In each case, the change revolves around an #ifdef for HAVE_RL_COMPLETION_APPEND_CHARACTER, so presumably I can use the same #ifdef to protect clear_history(). (Unless it's preferred to have a distinct flag for this, but I have zero autoconf knowledge/experience, so I might have to ask someone for help on that part.)

An extra advantage is that by testing for presence of the feature, you can cope with older Python versions is the same way as you cope with ancient readline versions.

Excellent point! I'll do it that way, then.

...

...

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.

That's always better, of course. How old were those log entries?

Last December there's a checkin by you of a patch from Magnus Lie Hetland to support 2.0/2.1, on the Python 2.3 branch. More recently, this support was backported to the Python 2.2 maintenance branch, and released in 2.2.3. In each case, the change revolves around an #ifdef for HAVE_RL_COMPLETION_APPEND_CHARACTER, so presumably I can use the same #ifdef to protect clear_history(). (Unless it's preferred to have a distinct flag for this, but I have zero autoconf knowledge/experience, so I might have to ask someone for help on that part.)

Nah, it looks like those featuers were introduced in the same GNU readline release, so it's okay to test for the same symbol. --Guido van Rossum (home page: http://www.python.org/~guido/)

Alex Martelli writes:

On Thursday 28 August 2003 01:28 am, Guido van Rossum wrote:

...

...

Hmmm... that makes me think of tests... I guess I won't really be able to supply a test for the feature, since that would just be testing whether the feature is available.

For interactive stuff like this, absence of unit tests is acceptable.

pexpect (or rebuilding some of its functionality on top of raw pty) should allow unit tests of textmode interactive stuff, though -- in theory, at least.

I suspect this approach would find more out about bugs in the pty implementations of old versions of Solaris than anything to do with Python. Cheers, mwh -- ... but I guess there are some things that are so gross you just have to forget, or it'll destroy something within you. perl is the first such thing I have known. -- Erik Naggum, comp.lang.lisp

[Michael Hudson]

Guido van Rossum writes:

...

Probably. I'm personally not so stringent for minor stuff like this (hey, I added bool() to 2.2.1 :-), but it seems others are increasingly resisting even minor feature additions in micro releases (except in the email package :-).

The problem with adding things like this is that it makes it harder to port code from *2.3.1 to 2.3* and at least in principle it would be nice if code that works on 2.3.1 works on 2.3 unless it tickles a specific bug that has been fixed.

And, come Panther, there are going to be rather a lot of Python 2.3 installs out there.

Just as a matter of interest, do you have any idea how many Mac OSX licensees there are? regards -- Steve Holden http://www.holdenweb.com/ Python Web Programming http://pydish.holdenweb.com/pwp/ Interview with GvR August 14, 2003 http://www.onlamp.com/python/

On Tuesday, September 2, 2003, at 01:14 AM, Steve Holden wrote:

...

And, come Panther, there are going to be rather a lot of Python 2.3 installs out there.

Just as a matter of interest, do you have any idea how many Mac OSX licensees there are?

Apple sells about 3 million machines per year (taking their Q3-02 and Q3-03 figures and interpolating from that:-) and since last year these boot into OSX by default (and, since the last couple of months they only boot into OSX). Adding the conversion factor from older machines I come to about 5 million. And, surprise, that's also what some other people came up with using a different method: <http://www.omnigroup.com/mailman/archive/macosx-talk/2003-August/ 015570.html>. But we're really interested in how many people will be running Panther, and I think that number is going to be lower. Very few people stuck with 10.1, basically only people whose machines wouldn't run 10.2 (pre-G3 processors), because 10.2 was really *way* ahead of 10.1. The 10.2->10.3 difference is probably less (to the non-Pythonic general community:-), so how about 1 million 10.3 users by the end of the year, 3-4 million by mid-2004? Any correspondence of these number with reality is pure chance, though:-) -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman