This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: after using pdb readline does not work correctly
Type: Stage:
Components: Library (Lib) Versions: Python 2.2
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: gvanrossum Nosy List: gvanrossum, mbrierst, mwh, nnorwitz, rhettinger
Priority: normal Keywords:

Created on 2003-01-28 20:53 by mbrierst, last changed 2022-04-10 16:06 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
patchreadline mbrierst, 2003-01-28 21:02
patchcmd mbrierst, 2003-01-28 21:03
patchreadline2 mbrierst, 2003-01-29 15:27
patchcmd2 mbrierst, 2003-01-31 21:25
patchcmd2 mbrierst, 2003-02-01 06:37
patchcmd2 mbrierst, 2003-02-01 06:41
patchcmd1.26.16.3 mbrierst, 2003-02-21 17:54
patchrdline2.41.6.4 mbrierst, 2003-02-21 17:55
Messages (18)
msg14274 - (view) Author: Michael Stone (mbrierst) Date: 2003-01-28 20:53
After I use pdb in the interpreter my readline settings are messed up.  It only knows about the pdb readline stuff forever afterward.  In fact, this happens as soon as a Pdb object is instantiated, regardless of whether or not you use it.

This is a result of some aspects of the Cmd object in Lib/cmd.py.

Currently Cmd registers a new readline completer as soon as a Cmd object is instantiated.  This is probably incorrect.  I believe the correct place to register the new handler is in the preloop hook.  That way the new readline completer is only used while the Cmd object is actually responsible for processing user input.

Next, the old readline completer should probably be re-registered in the postloop hook.  In order to do this, a new call must be added to the readline module to return the current completer so it can be saved and later restored.

The files included patch readline.c (version 2.41.64) and cmd.py (version 1.26.16.2) to make the changes described above.  After this patch readline works as expected in the interpreter.

Let me know what you think of it.
msg14275 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2003-01-29 10:36
Logged In: YES 
user_id=6656

I approve of this patch in principle.  I hadn't done enough
investigation to see that it was so easy to get the current
completer function!

OTOH:

return Py_BuildValue("O", completer);

is sick.  Change that to

Py_INCREF(completer);
return completer;

and if noone else howls, I'll check it in.
msg14276 - (view) Author: Michael Stone (mbrierst) Date: 2003-01-29 15:27
Logged In: YES 
user_id=670441

I attached a changed readline.c patch to hopefully get rid of any "sickness".
(There was a not-checking-for-null problem too... ouch)

I think it's good now.  But note, there may not be a way to do this sort of thing perfectly.  If you mess around enough with starting debuggers within debuggers (or in general anything that uses a Cmd object) it might be possible to end up with an unexpected completer function in the end.

And it looks like under the current system there's no way to get back the completer key that was initially used.  But this isn't SUCH a big deal since I think everyone uses tab, right?

At any rate, the change is definitely an improvement for me.
msg14277 - (view) Author: Michael Stone (mbrierst) Date: 2003-01-29 18:19
Logged In: YES 
user_id=670441

Actually, the readline library does have the functionality to get the current binding of the tab key, so it could be saved and restored.  However, to do this in python some stuff would have to be added to the readline.c module, to create some python layer that deals with the way readline stores macros, functions, and keymaps.  It's probably not worth the effort unless someone wants to do major changes to the readline module to add the full functionality of the underlying library to the python interface. 

Probably cmd.py shouldn't be rebinding the tab key to complete at all.  If the user wants that, won't they have already done it somewhere else, like in their pythonrc or inputrc files?  And if they don't it might be impolite to change their bindings.
msg14278 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2003-01-30 10:22
Logged In: YES 
user_id=6656

Thanks for the new patch, it looks OK.  There are a couple
of things that spring to mind for future patches: 

- the function should be METH_NOARGS (or you should check
the args tuple)

- there should be a blank line between the argspec line in
the docstring and the description

- you should use the PyDoc_STRVAR macro (but this was only
used in the CVS trunk's version of readline).

I made these changes and checked in revision 2.59 of
Modules/readline.c.

Wrt the cmd.py changes, I think I'll probably let that
sleeping dog lie.  I agree with you in general: cmd.py
probably shouldn't be rebinding any keys, but

1) the interface is "specify the completion key to get
completion",   so backwards compatibility raises its head

2) as you say, most people do probably rebind tab anyway

so I propose to check in your patchcmd, close the bug and
wait for someone to submit a bug report about pdb messing up
their bindings.
msg14279 - (view) Author: Michael Stone (mbrierst) Date: 2003-01-30 16:59
Logged In: YES 
user_id=670441

That sounds good to me.  Go ahead and check in patchcmd.

Thanks for your suggestions, I will follow them in future patches.  In this one, I was trying to follow the conventions I saw being used in the module, but they were outdated or incorrect (and I didn't always follow them correctly anyway!).  Okay that's definitely enough commentary for a few line patch.
msg14280 - (view) Author: Michael Stone (mbrierst) Date: 2003-01-31 21:25
Logged In: YES 
user_id=670441

I started using the latest cvs version today.
I have attached a diff to the latest cvs as patchcmd2 if that's
more convenient for you to apply.
msg14281 - (view) Author: Michael Stone (mbrierst) Date: 2003-02-01 06:37
Logged In: YES 
user_id=670441

I started using the latest cvs version today.
I have attached a diff to the latest cvs as patchcmd2 if that's
more convenient for you to apply.
msg14282 - (view) Author: Michael Stone (mbrierst) Date: 2003-02-01 06:41
Logged In: YES 
user_id=670441

I started using the latest cvs version today.
I have attached a diff to the latest cvs as patchcmd2 if that's
more convenient for you to apply.
msg14283 - (view) Author: Michael Hudson (mwh) (Python committer) Date: 2003-02-03 11:11
Logged In: YES 
user_id=6656

Checked in as 

Lib/cmd.py revision 1.34

Thanks!  You probably didn't need to attach the patch three
times, though :-)
msg14284 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2003-02-21 07:42
Logged In: YES 
user_id=80475

Backport?
msg14285 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2003-02-21 12:42
Logged In: YES 
user_id=6380

Good idea.
msg14286 - (view) Author: Michael Stone (mbrierst) Date: 2003-02-21 17:52
Logged In: YES 
user_id=670441

I'm attaching backported versions against
cmd.py 1.26.16.3
readline.c 2.41.6.4
if you want them.
msg14287 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2003-02-24 22:30
Logged In: YES 
user_id=80475

Assigning to Neal because I can't test this on my Windows 
machine.
msg14288 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2003-03-01 02:10
Logged In: YES 
user_id=6380

Neal, do you have a Windows machine to test this on? (It's
for Python 2.2.3)

(I'm not sure why this needs to be tested on Windows at all
- maybe because of the subtle changes to cmd.py?)
msg14289 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2003-03-01 02:19
Logged In: YES 
user_id=6380

I'll just check this in -- I don't see any reason to test it
on Windows. :-)
msg14290 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2003-03-01 02:24
Logged In: YES 
user_id=6380

OK, fixed. Who cares if this works on Windows. :-)
msg14291 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2003-03-01 15:15
Logged In: YES 
user_id=33168

:-) FYI, I do have Windows ME, but no development env't. 
The best I could do is cygwin.
History
Date User Action Args
2022-04-10 16:06:15adminsetgithub: 37857
2003-01-28 20:53:56mbrierstcreate