classification
Title: IndexError in sys.__interactivehook__ with pyreadline installed
Type: behavior Stage: needs patch
Components: Library (Lib) Versions: Python 3.4
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: jaraco, pitrou, python-dev, tshepang
Priority: high Keywords:

Created on 2014-01-27 20:12 by jaraco, last changed 2014-01-28 14:19 by jaraco. This issue is now closed.

Messages (6)
msg209471 - (view) Author: Jason R. Coombs (jaraco) * (Python committer) Date: 2014-01-27 20:12
Following the blame history, this appears to be new issue following issue5845.

I'm using Python 3.4b2 64-bit on Windows. I've installed pyreadline 2.0 using Setuptools 2.1. Now, when I start the interactive interpreter, I get this output:

> python
Python 3.4.0b2 (v3.4.0b2:ba32913eb13e, Jan  5 2014, 16:13:26) [MSC v.1600 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
Failed calling sys.__interactivehook__
Traceback (most recent call last):
  File "c:\python\lib\site.py", line 412, in register_readline
    if readline.get_history_item(1) is None:
  File "c:\python\lib\site-packages\pyreadline-2.0-py3.4-win-amd64.egg\pyreadline\rlmain.py", line 154, in get_history_item
  File "c:\python\lib\site-packages\pyreadline-2.0-py3.4-win-amd64.egg\pyreadline\lineeditor\history.py", line 52, in get_history_item
IndexError: list index out of range

It seems I don't yet have any history, and it seems that site.py is expecting get_history_item() to return None when no history is present, but the pyreadline 2.0 implementation does no such thing, but instead tries to index the history array directly, causing the IndexError.
msg209478 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-01-27 20:42
Sounds reasonably easy to fix. Can you write a patch?
msg209480 - (view) Author: Jason R. Coombs (jaraco) * (Python committer) Date: 2014-01-27 21:08
Is the proper fix to address the issue in site.py? Does this issue reveal anything else of concern about the implementation?

Assuming Yes and No, then yes, I can put together a fix.
msg209483 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2014-01-27 21:17
> Is the proper fix to address the issue in site.py? Does this issue
> reveal anything else of concern about the implementation?

I don't know, but it's a regression, so we'd better add a "fix" or
"workaround" in site.py anyway.
msg209550 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2014-01-28 14:18
New changeset ca6efeedfc0e by Jason R. Coombs in branch 'default':
Issue #20411: Use readline.get_current_history_length to check for the presence of a history, rather than get_history_item, which assumes a history is present.
http://hg.python.org/cpython/rev/ca6efeedfc0e
msg209551 - (view) Author: Jason R. Coombs (jaraco) * (Python committer) Date: 2014-01-28 14:19
After further consideration and investigation, I believe the fix is to simply use the API as exposed by pyreadline to check the length of the history to detect the presence of an existing history. I've tested that fix locally and it seems to be working suitably. Please review and suggest corrections as appropriate.
History
Date User Action Args
2014-01-28 14:19:58jaracosetstatus: open -> closed
resolution: fixed
messages: + msg209551
2014-01-28 14:18:12python-devsetnosy: + python-dev
messages: + msg209550
2014-01-28 14:11:47tshepangsetnosy: + tshepang
2014-01-27 21:17:27pitrousetmessages: + msg209483
2014-01-27 21:08:34jaracosetmessages: + msg209480
2014-01-27 20:42:21pitrousetpriority: normal -> high

nosy: + pitrou
messages: + msg209478

type: behavior
stage: needs patch
2014-01-27 20:12:12jaracocreate