Ask and answer¶
This page is about input(), the way a console program asks a person a question and waits for the answer. You will see what your program receives when someone types a line, presses Enter on an empty line, ends the input, or cancels, and you will learn where the limits are. In d/Python, input() is not a special case. It goes through the same versioned d/OS console service, CONSOLE.READ_LINE_RESULT, that INPUT uses in d/BASIC, d/OS's other language, which shares the same runtime. That is why the playground, the terminal and a native console window all behave the same way.
The shape of it¶
# stdin: "Zoë 🐍\n"
try:
name = input("Your name: ")
print("Hello, " + name + "!")
except EOFError:
print("No more input.")
The program evaluates the optional prompt, converts it to text the ordinary Python way (an object with __str__ works, and its side effects happen before the wait), writes it, then pauses until a line arrives. If you leave out the prompt, nothing is written; input(None) writes None, exactly as CPython does.
Three answers that are not the same¶
| What the person does | What the program sees |
|---|---|
| types a line and submits it | that line, without its trailing newline; an empty submission is "" |
| ends input | EOFError is raised, and it stays in effect, so a later input() raises again |
| cancels the read | d/OS stops the program with its standard cancellation (class STATE, rule 0xf02c); not EOFError, not KeyboardInterrupt |
The difference is deliberate. Reaching the end of input is an ordinary Python outcome you can catch. Cancelling is a decision made by the host, and it keeps its class, rule number and detail so you can always tell why the program stopped.
Exactly what you get back¶
The reference is CPython 3.9.6 in isolated mode reading from a UTF-8 pipe, and d/Python matches it. One trailing line feed is removed; spaces, carriage returns, NUL bytes and every valid Unicode character are kept; a final line with no newline is returned once, and the read after it sees the end of input. Bytes that CPython would decode with surrogateescape are not supported: the program raises an explicit NotImplementedError that says what is missing, and once you catch that exception the next line is still readable. A line longer than 65,535 UTF-8 bytes is never cut short: the shared length rule declines it, the playground declines it before sending it, and the line stays in the editor for you to fix.
In the playground¶
An answer row appears under the question. Enter submits; End input marks the end of input; Cancel read cancels. The host never copies what you typed into the program's output, so what you see in the console is exactly what the program printed. The playground keeps the last 65,535 bytes of output, and if anything before that was lost it reports the exact position rather than pretending the transcript is complete.
On the command line¶
dpython run program.py reads the reply from your terminal. It does this through a shared endpoint that holds its own close-on-exec copy of standard input, checks whether input is ready with a zero timeout, and never changes the terminal flags it inherited, so a normal exit, SIGINT, SIGTERM and SIGKILL all leave your shell exactly as they found it. That endpoint is macOS-only today. On Linux the same program declines to run READ_LINE_RESULT and says so (SERVICE_ROUTE_UNAVAILABLE), which is why the Linux corpus run of 12 September 2026 reports 65 of 66 programs passing; the browser and macOS paths are unaffected. A separate --console-window mode runs a console program beside a native console window written in d/BASIC, with Submit, End input, Cancel read and Stop program controls; see The macOS Kit.
What is not there¶
Configuring streams and encodings, replacing sys.stdin, readline history and surrogate strings are not yet supported. print(..., file=...) and flush= are not yet supported either. Each has a row in the compatibility table, and the compiler tells you by name when you use one.