By default, Pdb and other instances of Cmd complete names for their commands. However in the context of pdb, I think it is more useful to complete identifiers and keywords in its current scope than to complete names of commands (most of which have single letter abbreviations). I believe this makes pdb a far more usable introspection tool.

I have discussed this proposal on the python-ideas list:
http://mail.python.org/pipermail/python-ideas/2007-January/000084.html

This patch implements the following:
  - creates an rlcompleter instance on Pdb if readline is available
  - adds a 'complete' method to the Pdb class. The only difference with rlcompleter's default behaviour is that is also updates rlcompleter's namespace to reflect the current local and global namespace, which is necessary because pdb changes scope as it steps through a program

This is a patch against python/Lib/pdb.py rev. 51745

I experimented with this a little in the pydb variant (http://bashdb.sf.net/pydb). Some observations. First, one can include the debugger commands into the namespace without too much trouble. See what's checked into CVS for pydb; In particular look at the complete method of pydbbdb. (Personally, I think adding debugger commands to the list of completions is a little more honest.)

The second problem I have is that completion is not all that sensitive to the preceding context.  If the line begins "step" or "1 + ", is it really correct to list all valid symbols? 

Thanks for your comments, and thanks for pointing out pydb

I agree that debugger commands should also belong in the completion namespace. I'll have a look at adding that to the patch.

> The second problem I have is that completion is not all that sensitive to the preceding context.

The idea is that the namespace that is available to the completer at any time will be the same as the local and global identifiers and keywords that are available in the same scope. I think it makes sense to complete everything that is valid in the current scope because that makes for a more useful introspection tool. Thats what frame.f_locals and frame.f_globals are about (if foo and bar are available in the current scope, and you step into a function outside of that scope then foo and bar will no longer be available in the completer's namespace). I notice this is also used in pydb's complete method under certain circumstances.

I'll definitely take a closer look at pydb. I probably wouldn't have needed to write this if I'd known about it before :)