The guide, in human order

This page is the table of contents for the d/Python guide. It is arranged as a course you can read straight through or dip into, not an alphabetical wall of keywords. By the end of it you will know which chapter answers your question, and every chapter's code blocks open in the playground with one click.

Foundations

1 · Make something runThe playground, the command line, first contact, and the two kinds of program: console and window. 2 · Console or window?Console programs, window programs, and compiled programs that offer both. 3 · Count without limitsIntegers of any size, floor division, bit operations, pow, divmod, and where floats stop. 4 · Work with text and bytesUnicode, f-strings, slicing, the string methods that work, encode, repr and ascii. 5 · Work in collectionsLists, tuples, dictionaries, sets, ranges, two names for one object, and the one-element-type rule. 6 · Give it a plotif, while, for, else on loops, break, continue, chained comparisons. 7 · Give ideas namesSignatures, defaults, *args and **kwargs, lambdas, nonlocal, recursion. 8 · Stream, don't stackiter/next, enumerate, zip, map, filter, sorted, reversed, generator expressions. 9 · Model a worldClasses, inheritance, super(), the special methods that work, objects you can call. 10 · Handle trouble honestlytry/except/else/finally, raise, assertions, and with. 11 · Split it into filesimport, from-import, packages, relative imports, circular imports, __main__. 12 · Read an error messageCompiler messages, Python exceptions, and d/OS declining a request: three different things.

Applications and the outside world

13 · Ask and answerinput(), the end of input, cancelling, and the shared console service. 14 · Open a windowThe functions that handle a window's life, drawing with graphics intents, keys and pointer, asking for a redraw. 15 · Build an interfaceThe shared widget engine: create, place, style, hit-test, sync, destroy. 16 · Make a little gameTic-tac-toe, line by line: state, rules, an opponent, input, drawing. 17 · Ask the worlddos.intent, dos.service, dos.array, dos.decimal, and the official list of intents behind them. 18 · Files, hashes, sound, networkWhat the macOS host supplies to console programs: files, hashing, sound and the network. 19 · Share good codeCalling a shared library file, .dbl, from Python, and the rules about who owns what. 20 · Ship the applicationDPK2 packages, metadata, resources, icons, developer seals.

Delivery and truth

21 · Think like the compilercheck, build, inspect, trace, bindings; the same input always gives the same bytes; what is shared with d/BASIC. 22 · Build the Mac kitA folder you can move anywhere, with both programs, compiled examples and checks that it still works. 23 · Prove itThe reference CPython build, the test programs, the shared d/BASIC and d/Python suite, the checks a build must pass. 24 · Measure itProgram sizes, compile and run times, the WebAssembly modules, what a number does and does not mean. 25 · Find the builtinAll 69 Python 3.9 builtins with their status, what is tested, and what is missing. 26 · Find the boundaryThe 45-row compatibility table, drawn from the file the compiler ships with. 27 · Find the intentEvery intent you can call, and which ones have been run in a test.

The five ideas worth remembering

1. It is Python 3. The rules come from the language reference and one fixed CPython build, not from whatever is convenient for the runtime.
2. It is bytes. A program is a compiled .dbc file and the .dbl libraries it uses; no interpreter, no source and no CPython travel with it.
3. Partial is not complete. Every feature has a tested scope and a stated boundary; for the rest, the compiler stops at the line and says so.
4. Types are inferred, and the compiler tells you when it cannot. A list holds one element type; an empty container needs a known shape before it is printed in a loop.
5. Programs say what they want; hosts provide what they can. The dos module is the whole list of intents, typed for Python; a missing capability is a clear "no", never a fake.