homepage

The function set by readline.set_completer must return one completion per call. This should be great if we can return an iterable, because with current implementation I have to write a wrapper:
cache = None
def completer(text, state):
 if cache:
 if len(cache) > 0:
 return cache.pop(0)
 else:
 cache = None
 return None
 res = completer_returning_iterable(text)
 if isinstance(res, str) or res == None:
 return res
 cache = res
 return completer(text, state)
readline.set_completer(completer)
And completer_returning_list, the true completer, returns a pythonic iterable for all possible completion.

Is this a good, bad or indifferent idea?

I agree the design requiring it to pass the same information over and over is a bit odd (I've occasionally had cause to "borrow" some of ipython's niftyness for a plain Python terminal, and making custom completers work is one of the more awkward parts of the whole process). I'm guessing this is a product of conforming overzealously to the C API for readline functions like rl_filename_completion_function (see: http://cnswww.cns.cwru.edu/php/chet/readline/readline.html#SEC47 ).
It doesn't seem possible to do this nicely; __next__() on a generic iterator won't accept arguments (and practically, one of these arguments is state, the other is just "get next"), and trying to catch a TypeError due to the wrong number of arguments or using a generator as a string so you switch modes is ugly. Either the existing interface spawns additional arguments (also ugly; boolean flags that completely change behavior are the last refuge of a scoundrel), or a new function is created (possibly deprecating the old one over time.
Any suggestions?