Title: No prompt for "display all X possibilities" on completion-enabled input()
Type: behavior Stage:
Components: IO, Library (Lib) Versions: Python 3.2, Python 3.4, Python 2.7
Status: closed Resolution: duplicate
Dependencies: Superseder:
Assigned To: Nosy List: yoha
Priority: normal Keywords:

Created on 2014-11-23 09:45 by yoha, last changed 2016-01-31 09:09 by yoha. This issue is now closed.

Messages (3)
msg231550 - (view) Author: Yoha (yoha) Date: 2014-11-23 09:45
When running input() (or raw_input() for Python 2) while tab-completion has been enabled using `readline.parse_and_bind('tab: complete')`, pressing the tab key twice display the message `Display all X possibilities? (y or n)` when there are more than 100 remaining possibilities (default value). However, I am not asked any input to answer the question, and readline then proceeds to display all possibilities.

Steps to reproduce:

* run the following code: `__import__('readline').parse_and_bind('tab:complete');input()"`
* press tab twice

If your current directory has more than 100 files, the message `Display all X possibilities? (y or n)` should show, following by a list of the files.

The bug still shows up with:
* rlcompleter or custom completer
* versions 2.7.3, 2.7.8, 3.2.3 and 3.4.2
* bash or zsh
* tty, screen, ssh+screen, xterm, urxvt, gnome-terminal
* command-line flags -S (no `site` module), -u (unbuffered) or -Su
* being run as script, as `-c` command-line argument, or in the interactive interpreter
* `import readline;readline.` or `from readline import *` in stead of `__import__('readline').`

On the other hand, the C program "#include <readline/readline.h>", "main(){readline(0);}" behaves as expected: after the message is displayed, user input is waited for and typing "y" lists the possibilities, "n" resumes the line editing, and anything else is ignored.
msg231551 - (view) Author: Yoha (yoha) Date: 2014-11-23 09:49
Forgot to list the system: the bug has been tested and reproduced on Debian amd64, both wheezie and jessie.
msg231556 - (view) Author: Yoha (yoha) Date: 2014-11-23 12:18
I have found the culprit. It is actually coming from libreadline: <> where the answer is always set to yes in callback mode. According to `git blame`, this is has been so since version 6.2 at least three years ago.

Should Python patch its code to fix readline's behavior? Should I a bug be filed in the GNU maling list for readline? Should I wait and hope this is fixed someday?
Date User Action Args
2016-01-31 09:09:24yohasetstatus: open -> closed
resolution: duplicate
2015-11-28 06:25:51serhiy.storchakalinkissue16151 dependencies
2014-11-23 12:18:05yohasetmessages: + msg231556
2014-11-23 09:49:05yohasetmessages: + msg231551
2014-11-23 09:45:42yohacreate