> >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/)