The solution to raise a ValueError for the PyOS_Readline case won't change the behavior of input() in cases where the prompt is written to sys.stdout.

As to copying what print() would do, I guess it's possible to fake it for common platforms. You'd have to process the prompt string to emulate the platform behavior, which commonly means either ignoring '\0' or replacing it with space. However, this can't emulate raw console or terminal modes that actually write '\0'. 

A Linux terminal ignores '\0' characters written to it, e.g. "some\0text" prints as "sometext". I didn't look into modifying the terminal settings, but it wouldn't surprise me if different behavior is possible. 

The Windows console replaces '\0' with a space when the screen buffer is in the default cooked mode (i.e. ENABLE_PROCESSED_OUTPUT). For raw output it writes '\0' to the screen buffer, which displays like a space, but copy and paste won't work as expected.

> I am surprised it does not, as "input(prompt)" has been 
> described as shorthand for "print(prompt, end=''); input()"

That's how the fallback case works, such as in IDLE. In the readline case, it doesn't even write the prompt to C stdout. It gets written to stderr...

For Windows, if stderr is a console screen buffer, it transcodes the prompt from UTF-8 to UTF-16 and writes it via WriteConsoleW. Otherwise it calls fprintf to write it to stderr.