p5: Processing-style sketches in Python

Processing's ideas, with Python's syntax

p5 is a Python library that provides high level drawing functionality to help you quickly create simulations and interactive art using Python. The description of the audience is explicit: it combines the core ideas of Processing, which the readme summarises as learning to code in a visual context, with Python's readability to make programming more accessible to beginners, educators and artists.

That combination is the whole product. Processing gives you a draw loop that runs sixty times a second and a coordinate system and a set of drawing verbs, and p5 gives you the same shape in Python, where a teacher does not have to explain a Java class hierarchy before the first rectangle appears on screen.

The programs are called sketches, and the important detail is that they are run as any other Python program. There is no project format, no build step and no separate runtime. A sketch is a Python file that you execute.

The documentation is published at p5.readthedocs.io with a separate installation page, the issues are tracked on the repository's issues page, and anything that is a question rather than a bug is directed to a discourse platform at discourse.processing.org, in the p5py category. There is also a Slack group for the development community, which the readme offers as the place to get help if you are new to open source.

The example sketch is the whole API in twenty lines

The readme includes the source of its example sketch, and reading it explains the library's design better than any description of the API would.

A sketch is a Python module with functions named setup, draw and key_pressed. The setup function runs once, the draw function runs on every frame, and the event handlers are also plain functions with names that describe the event.

Inside them, the drawing calls are free functions, imported with a wildcard import:

from p5 import *

def setup():
    size(640, 360)
    no_stroke()
    background(204)

def draw():
    if mouse_is_pressed:
        fill(random_uniform(255), random_uniform(127), random_uniform(51), 127)
    else:
        fill(255, 15)

The mouse position is available as a global, mouse_x and mouse_y, and the mouse state as mouse_is_pressed, so a beginner does not have to write an event handler to react to a click. The colour is a random value with a range given by keyword arguments, low and high, and the alpha channel is the last argument to fill.

The shape of this is the Processing shape, exactly. A sketch reads as a sequence of drawing commands in a loop, and the amount of machinery between the idea and the picture is close to zero.

Two renderers, and the default is not the recommended one

p5 supports different backends to render sketches, and the readme is unusually blunt about which one to use.

There are two. Vispy handles both 2D and 3D sketches, and Skia handles 2D sketches. The recommendation is to use Skia for a better 2D experience, and the comment in the example sketch says it plainly, use skia for better 2D experience. The default renderer is set to vispy, and Skia is still in beta.

So a new user gets the older renderer by default and is told to switch for a better result, in a project where the better renderer is not the finished one. That is an honest position, and it has consequences for a course: the code you write is the same either way, because the change is the renderer argument to run, but the behaviour and the performance differ.

The dependency list explains where each renderer comes from. Vispy is pinned to exactly 0.10.0, with glfw at 2.5.9 or newer for the window, PyOpenGL and PyOpenGL-accelerate both at 3.1.10, and numpy for the array work. The Skia path is skia-python at 85.0 or newer. Pillow at 10.4.0 or newer handles images, and requests at 2.25.0 or newer is there for network calls.

The exact pin on vispy is the one that will bite in a teaching environment, because a student with a newer vispy already installed will not get the version p5 was written against.

A plain setup.py, a metadata file and a long requirements list

The packaging is old fashioned, which is not a criticism but is a fact that affects installation.

setup.py reads its name, version, description, author, url, email and licence out of a metadata file inside the package, p5/__version__.py, by executing that file, and it reads the long description from README.rst with the content type text/x-rst. The package list comes from find_packages and the requirements are read straight out of requirements.txt rather than being declared inline.

The Python floor is 3.8, and the classifiers list 3.8 through 3.13, so the intent is to support the current range of interpreters. The development status classifier says 3 - Alpha, and the audience classifiers name developers and education, with topics for artistic software, education and multimedia.

The requirements file shows how heavy the dependency set is for a drawing library: glfw, numpy, Pillow, vispy, PyOpenGL with its accelerate companion, requests, skia-python, plus a dataclasses backport for Python 3.6 and a setuptools requirement for Python 3.12 and later.

Two directories in the repository are easy to overlook. There is a profiling directory, which suggests the maintainers have looked at where the time goes, and a project-wrapups directory, which usually holds notes about the wider ecosystem rather than the library itself.

GPL v3 for the code, LGPL for the borrowed shaders

The licence section is short and has a second layer.

p5 is licensed under the GPLv3, with the LICENSE file holding the details. In addition, the project includes components from other open source projects, and the one named is the OpenGL shaders from the Processing project, which are licensed under LGPL v2.1, with the full text in LICENSES/lgpl-2.1.txt. All the licences for these external components live in the LICENSES folder at the root of the repository.

That combination is the normal outcome of porting a library that carries assets rather than only code. The shaders are the visual core of the renderer, and shipping them under LGPL v2.1 inside a GPLv3 project is compatible, because the LGPL is designed to be combined with a GPL work, and the obligation is to keep the shaders themselves available under their own terms.

For anyone who wants to reuse p5 in a classroom, a workshop or a larger application, the practical point is that the GPLv3 applies to the library, and the shaders are a separate grant inside it rather than something that loosens the whole thing.

The repository also carries a .pylintrc and an .eslintrc style of tooling for the JavaScript side, along with a MANIFEST.in, a CONTRIBUTING.rst and a SUPPORT.rst, which together describe a project with a full support structure even if the release cadence is slow.

Support comes through a forum and a Slack, and the versions are uneven

The release history is where the project's pace becomes visible.

Version 0.8.3 was published on 2023-11-17 with the note that it stabilises the Skia renderer, and 0.8.4 on 2023-12-06 with support for Python 3.11 and bug fixes. Then a long gap, and version 0.9.0 on 2026-06-03, with the last push to the repository on the same date.

So the Skia renderer was stabilised in late 2023, in the same release that moved the project forward to a new Python, and then the project was quiet for more than two years before the next version. The 0.9.0 release note in the list carries no description, which usually means a version bump rather than a feature announcement.

The support structure has not changed in that time. Questions go to the discourse platform, bugs and feature requests to the issues page, and there is a Slack group for contributors, with the readme encouraging newcomers to start by fixing existing issues. The Slack badge, the monthly downloads badge from pepy and the build-tests workflow badge complete the picture of a small, well-organised project rather than a busy one.

For an educator that matters less than it would for a production dependency. For a production dependency, the two and a half year gap between 0.8.4 and 0.9.0 is the number to look at, and the alpha development status classifier says the same thing in a shorter form.

Editorial conclusion

p5 fits a teacher, an artist or a beginner who wants the Processing model, a draw loop and immediate visual feedback, in Python rather than in Java, because the whole library is a set of global functions and two callbacks and a sketch is a script you run. It is the wrong choice if you want a production rendering stack, since the Skia backend that the readme recommends for 2D is still in beta while the default Vispy renderer is the older option, and it is the wrong choice if you need a stable, actively released package, because the newest release is 0.9.0 from 2026-06-03 and the release before it dates from December 2023. Before you adopt it, decide which renderer you will teach with, read the installation page rather than guessing from the dependency list, and check the pinned vispy version against your own environment, since the requirements file pins it exactly.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. p5py/p5 on GitHub
3. Project website
4. README
5. Releases