prompt_toolkit
is a library for building powerful interactive command line applications in Python.
Read the documentation on readthedocs.
ptpython is an interactive Python Shell, build on top of prompt_toolkit
.
prompt_toolkit
could be a replacement for GNU readline, but it can be much more than that.
Some features:
Feel free to create tickets for bugs and feature requests, and create pull requests if you have nice patches that you would like to share with others.
pip install prompt_toolkit
For Conda, do:
conda install -c https://conda.anaconda.org/conda-forge prompt_toolkit
prompt_toolkit
is cross platform, and everything that you build on top should run fine on both Unix and Windows systems. Windows support is best on recent Windows 10 builds, for which the command line window supports vt100 escape sequences. (If not supported, we fall back to using Win32 APIs for color and cursor movements).
It's worth noting that the implementation is a "best effort of what is possible". Both Unix and Windows terminals have their limitations. But in general, the Unix experience will still be a little better.
The most simple example of the library would look like this:
from prompt_toolkit import prompt if __name__ == '__main__': answer = prompt('Give me some input: ') print('You said: %s' % answer)
For more complex examples, have a look in the examples
directory. All examples are chosen to demonstrate only one thing. Also, don't be afraid to look at the source code. The implementation of the prompt
function could be a good start.
The source code of prompt_toolkit
should be readable, concise and efficient. We prefer short functions focusing each on one task and for which the input and output types are clearly specified. We mostly prefer composition over inheritance, because inheritance can result in too much functionality in the same object. We prefer immutable objects where possible (objects don't change after initialization). Reusability is important. We absolutely refrain from having a changing global state, it should be possible to have multiple independent instances of the same code in the same process. The architecture should be layered: the lower levels operate on primitive operations and data structures giving -- when correctly combined -- all the possible flexibility; while at the higher level, there should be a simpler API, ready-to-use and sufficient for most use cases. Thinking about algorithms and efficiency is important, but avoid premature optimization.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4