Keyboard shortcut ('O") interfering with input()

I’ve installed Jupyter Notebook 3 times today on a new computer hoping to fix the problem with a keyboard shortcut. If the user types ‘o’ anywhere in response to an input() command, the text box disappears and all you see is an elipsis and the tiny message ‘click to expand’. The shortcut is set to ‘Toggle visibility of selected output cells.’ The effect is that a user cannot provide any input containing ‘o’. What I also can’t understand is that ‘show shortcut keys’ before loading a notebook displays an entirely different list of shortcuts than it does after loading a notebook. Before a notebook is loaded, no shortcut key to toggle visibility of output cells is even listed. I have tried unsuccessfully to find an easy way to override the ‘bad’ shortcut.

Can you specify what version of Jupyter Notebook exactly you were referencing?

I can confirm that I am seeing what you say happening when I launch a MyBinder session from the main Jupyter Notebook repo using the ‘launch binder’ badge. That launch gives Jupyter Notebook version 7.5.0 at present. Typing in a lowercase o to an active input() entry results in it hiding the output. I can click the elipses to toggle it back open; however, there is then no o represented in what has been entered. I am then able to continue typing as long as I do not enter a lowercase o. Entering an uppercase O is fine. Tested in Chrome, Firefox, and Safari so far.

Weird thing is that I cannot find an issue post for this at the repo? I must be missing it?

JupyterLab v4.4.9 does not have this issue.



I think the explanation for that part is relatively straightforward: what is shown may be context-dependent.
That would be consistent with a modern Jupyter versions, both JupyterLab and Jupyter Notebook, which now based on the same components as JupyterLab, where what is displayed to the user are very context dependent.

Thank you for your response! I am strangely comforted knowing you can replicate the behavior. I, too am using 7.5.0. The only workaround for now is to ask for responses to input() that have no ‘o’.

I also found it odd that this was not previously flagged by anyone as a real issue.

If you care, there are actually additional other work arounds, as input() is a legacy thing from consoles and not really meant for modern Jupyter with much more polished, full-featured collection of text from users. See here for some related discussion of options. (See the next paragraph as input() indeed now works in JupyterLite, which originally prompted that discussion.)
input() wasn’t even working typically in JupyterLite until more recently. They went through great effort to get it working as it is a traditional crutch used in teaching novices, see here under ‘Interactive Input Support’:

“Since input() is used quite extensively in introductory Python courses, this new feature should help make teaching with JupyterLite easier!”

Ah this must be a bug introduced by https://github.com/jupyter/notebook/pull/7709 which was added in Notebook 7.5. Thank you for reporting @Britt_Lowry and thanks for looking into it @fomightez.

1 Like

I opened https://github.com/jupyter/notebook/issues/7781

1 Like

Thanks all.

@Britt_Lowry hopefully https://github.com/jupyter/notebook/pull/7782 should fix the issue, and will be released in 7.5.1.

1 Like