[IPython-dev] ipython/pydb integration - readline

Ville M. Vainio vivainio at gmail.com
Mon Oct 30 07:47:10 CST 2006


On 10/30/06, R. Bernstein <rocky at panix.com> wrote:

> called "symbol". But two other solutions I think that are simpler at
> least from the caller's standpoint is to give the position of the
> start of the word or a regexp to use to search back to instead of the
> default look-for-blank (or maybe its look-for-non-alphanum) regular
> expression that is implied previously.

I think the caller's simplicity is slightly irrelevant here - the data
structure would be constructed only once and passed to possibly
several hooks, which need to be fast.

> Here's why I find this nicer. My guess is more than half of the time
> the call needs only to be:
>
>    complete_symbol(line)

As I see it, the easiest (and probably most typical) use is:

if event.command == 'apt-get':
  return [c for c in ['dist-upgrade','upgrade', 'update']  if
c.startswith(event.symbol)]

> will suffice. The thing about the object parameter interface is that
> the caller has to create it. And the line portion is *not* optional,

It's easy & cheap to create (and importantly, extend, without having
to alter the existing hooks).

> so why not make that a required parameter? It reduces run-time errors

In my example above, the use of whole 'line' is optional.

> at least in that aspect. And I don't see a need for giving the
> "command" part because at least in my uses, I arrange for what the
> valid completions can be *in advance* of the completion calls.

Again, see the example above. The 'command' makes it really easy to
implement many of the hooks.

A drawback with event object in hooks is that the signature of the
hook function does not fully document the behaviour of the hook, but I
believe we can be quite informative about it in our exceptions and
docstrings.

-- 
Ville M. Vainio - vivainio.googlepages.com
blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'


More information about the IPython-dev mailing list