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.

Title: When Caps Locked, + alpha-character still displayed as uppercase
Type: behavior Stage:
Components: IO, Windows Versions: Python 2.7
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: eryksun, jedwards, paul.moore, principia1687, steve.dower, tim.golden, zach.ware
Priority: normal Keywords:

Created on 2015-04-23 05:05 by principia1687, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Messages (7)
msg241845 - (view) Author: James (principia1687) Date: 2015-04-23 05:05
Referring to Python 2.7 running on Windows (7/8): 

At the interactive interpreter, if either 1) Caps are Locked OR 2) <Shift> is held while an alpha-character is selected, the character is output and displayed as uppercase, as one would expect. However, in Python 2.7, when Caps are Locked AND <Shift> is held while an alpha-character is selected, the output is still uppercase, when it should be lowercase.

This behavior seems to be limited to Python 2(.7), and only when Python is run interactively using the Windows console. When Python 2.7 is started through Cygwin using mintty on Windows 7/8, the behavior is not reproducible. The same goes for IDLE, as well as when running python interactively on Ubuntu. The behavior is reproducible using IPython when run in the standard Windows console, but is not reproducible when Python is run using the IPython QtConsole.

To summarize:

-----------------------------       -------------------------------
AFFECTED                    |      |NOT AFFECTED                 |
------------------------------      -------------------------------
python 2 via cmd (Windows 7/8)     python 3 via cmd    (Windows 7/8)
ipython via cmd  (Windows 7/8)     IDLE python 2 & 3   (Windows 7/8)         
                                   python 2 via mintty (Windows 7/8)
                                   python 2 via bash  (Ubuntu 14.04)
                                   ipython qtconsole   (Windows 7/8)
msg241849 - (view) Author: Tim Golden (tim.golden) * (Python committer) Date: 2015-04-23 07:18
Perhaps unsurprisingly, I can't reproduce this on Python 2.7.9 32-bit running on Win7 Home Premium. 

Python doesn't handle CapsLock/Shift interaction directly: it just gets what it gets from the underlying OS or framework. So I'm at a loss to know what might cause the effect you're seeing in so particular a way as to affect one version of Python in one i/o framework but not another.

Can you reproduce the situation on a different machine?
msg241901 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2015-04-24 00:11
Are you using pyreadline? It's commonly used with IPython. Pyreadline hooks PyOS_ReadlineFunctionPointer to provide readline functionality in the REPL. Since it accesses the console input via ReadConsoleInputW events instead of using ReadConsoleW, it wouldn't surprise me if it's mishandling the keyboard state.
msg241963 - (view) Author: James Edwards (jedwards) * Date: 2015-04-24 17:35
If you start the interactive interpreter with the -S switch, e.g.

    >python.exe -S

Do you still see this behavior?
msg241992 - (view) Author: James Edwards (jedwards) * Date: 2015-04-25 03:43
It looks like this is a bug in pyreadlines as suggested by eryksun, but for a different reason.

Even though the Caps Lock + Shift combination is recognized correctly (as lower case), the logic in the pyreadlines module forces it to upper case.

See lines 44-45 and 72-75 in [1].

You should be able to verify this by launching with the -S option, disabling the auto import of the site module.  (You'll need to import sys; sys.exit(), or Ctrl+Break to exit the interpreter -- exit() won't be defined.)

Given that pyreadlines looks to be somewhat of a mess and since you don't actually need pyreadlines to run ipython[2], you might consider uninstalling it (Alternatively, removing the "or shift" part of the referenced conditions will fix your specific issue).

If you're only looking for windows terminal coloring, colorama[3] is being used by the pip maintainers with apparent success.

In any case, it doesn't look to be an appropriate bug for this tracker -- maybe the pyreadlines github?

msg241995 - (view) Author: James (principia1687) Date: 2015-04-25 06:28
When I start the interpreter with the -S switch, the problem goes away. 
Thanks for looking into it, and I apologize for the false alarm!
msg242012 - (view) Author: Eryk Sun (eryksun) * (Python triager) Date: 2015-04-25 12:21
> It looks like this is a bug in pyreadlines as suggested by 
> eryksun, but for a different reason.

As I said before, it reads keyboard input events at a lower level via ReadConsoleInputW, instead of calling ReadConsoleW to read the input buffer as a text stream. To elaborate, this means it has to be aware of the keyboard state, per the [KEY_EVENT_RECORD][1] dwControlKeyState. This gets passed to [make_KeyPress][2] as `state`, which in turn ignores the CAPSLOCK_ON flag.

Date User Action Args
2022-04-11 14:58:16adminsetgithub: 68223
2015-04-25 12:21:19eryksunsetmessages: + msg242012
2015-04-25 06:31:11principia1687setstatus: open -> closed
resolution: not a bug
2015-04-25 06:28:34principia1687setmessages: + msg241995
2015-04-25 03:43:31jedwardssetmessages: + msg241992
2015-04-24 17:35:58jedwardssetnosy: + jedwards
messages: + msg241963
2015-04-24 00:11:16eryksunsetnosy: + eryksun
messages: + msg241901
2015-04-23 07:18:46tim.goldensetmessages: + msg241849
2015-04-23 06:09:59SilentGhostsetnosy: + paul.moore, tim.golden, zach.ware, steve.dower
components: + Windows
2015-04-23 05:05:31principia1687create