When the compiler says no

When a d/Python program does not run the way you hoped, the message you get comes from one of three places, and each looks different on purpose. The compiler may stop before producing anything, with a line and a column. Your program may raise a Python exception while it runs, which you can catch. Or d/OS, the operating system that brings modern software to 8-bit home computers such as the Atari 800, the Commodore 64 and the Apple II, may decline to run the program at all. This page shows what each one looks like and what to do about it. Telling them apart is part of learning the language.

A compiler message

main.py:1:9: call to `float` is not supported yet
main.py:4:11: text method lower is not implemented yet
main.py:7:8: mixed element types in a Python list need the tagged-value adapter
main.py:9:42: mixed-type and/or results are not supported yet
main.py:12:12: recursive result type is not yet inferable; put a concrete base-case return before the recursive call
main.py:2:1: Python formatting is not implemented for this value type; no BASIC formatting is substituted

Each of these means the compiler reached something d/Python does not support yet and stopped, telling you the file, the line and the column, in plain words. No program was produced. This is the first of d/Python's promises: a feature that is not supported gets a clear message, never a program that quietly does something slightly different. In the browser playground the message appears under the editor; the dpython command line prints it and exits with status 2. The compatibility table (the ledger, the machine-readable compatibility table) lists every one of these gaps with the reason it is still open, and the wording of a message usually matches the wording of its entry there.

Syntax errors are reported the same way:

main.py:2:1: unexpected token

A Python exception

try:
    int("x1")
except ValueError as error:
    print("ValueError:", error)

Here the program compiled and ran, and Python's own rules produced an exception, with the same class and message CPython would give. It travels out through finally blocks and with statements, it can be caught, and if nothing catches it the program ends with a non-zero exit status. See Exceptions & Context Managers. d/Python deliberately raises NotImplementedError when a running program reaches a gap that only shows up at run time, such as a negative exponent in pow or input bytes that cannot be decoded. The message says what is missing, and you can catch it like any other exception.

d/OS declines to run the program

D/OS refusal: CAPABILITY, rule 285, detail 0.
D/OS refusal: STATE, rule 61484, detail 0.

The third kind comes from d/OS itself rather than from your program. The d/OS runtime (the program that runs your compiled code), the loader that starts it, or the part of the host that supplies files, sound or the network may decline to go on: a library the program needs was missing before it printed anything, a permission the program needs was not granted, a request for memory could not be met, a read from the keyboard was cancelled, or this host has no file, sound or network service at all. d/OS calls this a refusal, and that is the word in the message. It carries a class (such as CAPABILITY or STATE), a rule number and a detail, and, when a service is too old, the version the program needs and the version on offer. It is not a Python exception and except does not catch it; it keeps its own shape so the reason can be read the same way on every machine. This is exactly why the console file, sound and network examples on this site do not run in the browser: the browser host has no FILE, AUDIO or NET service (d/OS's names for the parts of the host that supply files, sound and the network), the compiled program declares that it needs one, and saying so plainly is better than pretending.

When a Python integer is handed to a d/OS call that expects a number of a fixed size, and the value does not fit, d/OS declines before converting it; the value is never silently cut down. Those cases are also separate from Python exceptions.

Running out of room is a stop, not a wrong answer

A string longer than 65,535 bytes, more than 256 objects alive at once, more than 128 nested calls, a request for memory that cannot be met: each of these either stops the program with a d/OS message or raises an error you can catch. Every one is written down and tested, and none of them ever changes the result of a calculation. d/Python's design rules say this outright: a smaller program file or a faster path does not count as an improvement if it quietly changes what Python code does.

Reading the playground

Status	Meaning
a message under the editor	the compiler stopped; fix the line, or look the feature up in the compatibility table
Exited with status n	a Python exception was not caught, or the program ended on purpose with that status
Refused with a class and rule	d/OS declined; the cause is the host or what the program requires, not your algorithm
Waiting for input	input() is waiting for you; type an answer, end the input, or cancel

The line the compiler counts

Lines are counted from 1 at the top of the file and columns from 1 at the left, and the playground and the command line report the same numbers.