prompt_toolkit: building interactive Python command line applications without readline

What prompt_toolkit replaces, and for whom

The library positions itself as a possible replacement for GNU readline, but the README is explicit that it "can be much more than that." That distinction matters. readline gives you line editing and history for a single line of input. prompt_toolkit gives you multi-line input editing, completion, syntax highlighting of the input while typing, auto suggestions, multiple input buffers, mouse support and full-screen layouts. The intended audience is developers building interactive command line applications in Python, not people who want a nicer input() call. If your program reads one value and exits, the readline module already in the standard library is enough and adds nothing to your dependency list. prompt_toolkit earns its place when the input surface itself is part of the product: a REPL, a database shell, an SSH administration console, a configuration wizard with dialogs. The gallery points at ptpython as the reference application built on top, which is a useful signal about the scale of interface the library is designed to carry.

The layered architecture and why there is no global state

The philosophy section of the README is unusually specific for a library of this kind, and it describes an actual design constraint rather than a marketing position. The stated rule is that the code should be readable, concise and efficient, with short functions whose input and output types are clear, composition preferred over inheritance, and immutable objects where possible. The architectural claim is layered: lower levels operate on primitive operations and data structures, and when combined correctly they give all the flexibility, while a higher level offers a simpler ready-to-use API sufficient for most cases. The most consequential line is the commitment to no changing global state, so that multiple independent instances of the same code can run in the same process. That is what makes it possible to run a prompt inside a thread, a test harness or an async event loop without the two prompts fighting over terminal state. It is also why the library carries only two dependencies, Pygments for syntax highlighting and wcwidth for wide character column counting, rather than pulling in a terminal abstraction layer.

Installing prompt_toolkit and a first prompt

The README gives two installation paths. The pip route is the common one, and a Conda package is published on conda-forge for environments that manage their Python that way.

pip install prompt_toolkit

conda install -c https://conda.anaconda.org/conda-forge prompt_toolkit

The smallest working program in the README is three lines. It calls prompt() with a message and prints whatever the user typed, so running it should show the message, accept a line of input with full editing behaviour, and echo it back with the "You said: " prefix.

from prompt_toolkit import prompt

if __name__ == '__main__':
    answer = prompt('Give me some input: ')
    print('You said: %s' % answer)

For anything past that, the README points at the examples directory and says each example is chosen to demonstrate only one thing. That is the right place to start rather than the API reference, because the examples are organised by feature area: prompts, choices, dialogs, full-screen, progress-bar, print-text, ssh and telnet. The repository also ships a tutorial directory, and the documentation on readthedocs is the canonical reference. One practical note: the README suggests reading the implementation of the prompt function itself as an entry point into the source, which is a reasonable route given the stated preference for short functions.

Where the Windows story stops being equal

The README is candid here in a way that many cross-platform libraries are not. It states that Windows support is best on recent Windows 10 builds, for which the command line window supports vt100 escape sequences, and that where those are not supported the library falls back to Win32 APIs for colour and cursor movement. It then describes the implementation as "a best effort of what is possible" and notes that both Unix and Windows terminals have their limitations, with the Unix experience generally a little better. Read that as a real constraint, not a disclaimer. If you are shipping an interactive application to Windows users on older builds, or through a terminal emulator that does not pass escape sequences through, the colour and cursor behaviour you get is the fallback path, and features that depend on precise cursor positioning will look different from the Unix build. The README does not document which specific features degrade on the fallback path. That is the gap to close yourself if Windows matters to you.

prompt_toolkit vs click: different layers, not competitors

People search for a comparison between prompt_toolkit and click, and the honest answer is that they solve different problems. Click is an argument parsing framework: you declare options and commands, and it turns a command line invocation into a function call. prompt_toolkit is an input layer: it takes over the terminal while your program is running and gives the user an editable, completable, highlighted input surface. A click application finishes parsing and then runs; a prompt_toolkit application is still drawing the screen while the user types. You can use both in the same program, and the README's own framing supports that reading, since it describes prompt_toolkit as a readline replacement rather than a CLI framework. The real alternative to weigh is the standard library readline module, which is already present, has no dependency cost, and is the correct answer for single-line input. Choose prompt_toolkit over readline when you need multi-line editing, completion, syntax highlighting or full-screen layout; choose it over click only if you have confused the two problems.

Maintenance, the Python version floor and the licence

The last push to the repository was on 2026-07-26, and the most recent release is 3.0.53, published the same day. The release before that, 3.0.52, dates from 2025-08-27, and 3.0.51 from 2025-04-15. So the cadence is patch releases spaced months apart, with no sign of a 4.x line in the release list. The package metadata declares Development Status 5, Production/Stable, and requires-python is ">=3.10", with classifiers listing 3.10 through 3.14 and Free Threading 3 as Stable. That floor is the upgrade cost to plan for: if you are still on Python 3.9, this version will not install, and the pip resolver will tell you so rather than failing at runtime. The only runtime dependency is wcwidth>=0.1.4. Development dependencies in the pyproject.toml include mypy, ruff, pytest, coverage and prek, which tells you the project runs type checking and linting as part of its own workflow, though that says nothing about the type coverage of the public API. The licence is BSD-3-Clause, a permissive licence that permits use in closed-source products; the repository ships a LICENSE file and the classifiers mark it OSI Approved. That is a summary of what the metadata states, not legal advice.

What to check before you commit to it

Two things are worth verifying in your own environment before you build on this. First, run the three-line prompt example from the README in the terminal you actually target, on the platform you actually ship to, and watch the cursor behaviour and colour rendering. The README's own wording about best effort on Windows means the answer is terminal-specific, and no amount of reading the documentation substitutes for that check. Second, read the CHANGELOG entry for 3.0.53 rather than assuming a patch release is inert; the version string appears in both pyproject.toml and docs/conf.py, which the file comments note must be kept in sync, and that is the kind of detail that occasionally slips in a release. The examples directory is the fastest way to judge whether the library's idea of a dialog, a progress bar or a full-screen layout matches yours, and each example is deliberately scoped to one feature, so you can read them quickly. If those examples look like the interface you are trying to build, the dependency cost is two packages and the API surface is the one you want.

Editorial conclusion

Adopt prompt_toolkit when you are writing a Python CLI that needs multi-line editing, completion, syntax highlighting or full-screen layouts, and you are on Python 3.10 or newer. Do not adopt it if you only need argument parsing, or if you must support an old terminal where vt100 escape sequences are unavailable on Windows. Verify first that the prompt() call in the README example behaves as you expect in your target terminal, and check the CHANGELOG for the 3.0.53 entry before pinning a version.

Frequently asked questions

Official sources

1. License: BSD-3-Clause
2. Project website
3. prompt-toolkit/python-prompt-toolkit on GitHub
4. README
5. Releases