I haven't experience with Python C code but I tried to find some clues in the code. First for input(): it call PyOS_Readline which may call PyOS_StdioReadline > my_fgets > fgets in Parser/myreadline.c. There is Windows related comment on line 56:

“Ctrl-C anywhere on the line or Ctrl-Z if the only character on a line will set ERROR_OPERATION_ABORTED. Under normal circumstances Ctrl-C will also have caused the SIGINT handler to fire which will have set the event object returned by _PyOS_SigintEvent. This signal fires in another thread and is not guaranteed to have occurred before this point in the code. 
Therefore: check whether the event is set with a small timeout. If it is, assume this is a Ctrl-C and reset the event. If it isn't set assume that this is a Ctrl-Z on its own and drop through to check for EOF.”

For sys.stdin.readline and .read: it goes down the IO machinery from text IO, buffered IO and raw IO (in this case FileIO) to Modules/_io/fileio.c where it ends calling function read(fd, buf, len), probably from <unistd>. I don't know how read is implemented on Windows.

I also tried calling ReadConsoleW from winapi via ctypes to read Unicode charactes from console (see http://bugs.python.org/issue1602). And there was similar issue with Ctrl-C occurring. What seems to work here is to put time.sleep(0.01) after ReadConsoleW.

So the general pattern is following: when calling some low-level Windows function to read input from user and when he hits Ctrl-C, the function returns and SIGINT is generated. However it takes time for this signal to arrive. Because it may arrive anywhere in the following code, the strange behaviour may occur. In the input() case, when PyOS_Readline returns, it was probably enough time, so added PyErr_CheckSignals() catched that SIGINT/KeyboardInterrupt.

We can find out about Ctrl-C having been pressed by calling winapi function GetLastError() and testing against ERROR_OPERATION_ABORTED. Then we should wait for the signal.