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)

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?

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.

If you start the interactive interpreter with the -S switch, e.g.

    >python.exe -S

Do you still see this behavior?

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?


[1] https://github.com/pyreadline/pyreadline/blob/master/pyreadline/keysyms/common.py
[2] http://mail.scipy.org/pipermail/ipython-dev/2013-November/012623.html
[3] https://pypi.python.org/pypi/colorama

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!

> 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.

[1]: https://msdn.microsoft.com/en-us/library/ms684166
[2]: https://github.com/pyreadline/pyreadline/blob/master/pyreadline/keysyms/keysyms.py#L116