pypresence wraps Discord IPC so a Python script can set its own Rich Presence

Discord IPC is a socket handshake, and an authorized app is the gate

Discord shows what you are playing or running in the status area next to your name, and the protocol behind that is not a public REST call but a local IPC connection that the client establishes on the machine. Any Python tool that wants to appear in that status bar has to speak that protocol correctly, including the handshake and the payload shape the client expects. pypresence exists to hide that layer. It describes itself as a Discord RPC client written in Python and its topic list includes both rich presence and a generic wrapper role, so it is aimed at developers who want the convenience of an import rather than a socket implementation of their own. The audience is narrow and clearly defined: a script or application that wants to advertise a name, a detail line, state, and timestamps to a Discord client that is already logged in on the same machine. The single most consequential line in the documentation is a note placed above the links: you need an authorized app to do anything besides rich presence. In other words, Rich Presence is the supported use case of this library, and anything wider requires credentials and permissions that belong to a Discord application rather than to your Python package. That constrains the design space in a way that matters for evaluation. If you are building a bot, a moderation tool, or anything that acts on a server, this is the wrong library. If you are building a game launcher, a music player, a build watcher, or a terminal tool that should show what it is doing, the authorized app requirement is a one time setup for you as the developer rather than a runtime dependency for your users.

The examples folder is wider than the README

The README shows no code at all beyond an installation note, and instead points at an examples directory that contains sixteen entries. The names alone sketch out the surface area the author expected people to need: examples/rich-presence.py, examples/rich-presence-music.py, examples/rich-presence-loop.py, examples/rich-presence-images.py, examples/rich-presence-gifs.py, examples/rich-presence-with-urls.py, examples/rich-presence-custom-name.py, examples/rich-presence-program-detection.py, examples/rich-presence-cpu-usage.py, examples/rich-presence-get-request.py, examples/time-elapsed-example.py, examples/buttons.py, examples/full-event-client-example.py, and a Markdown file named examples/client-authorize-example.md. There is also examples/examples.md, which the README describes as the place to read before contributing an example of your own. For a newcomer, that folder is the effective documentation, and the naming suggests coverage of events, media, and authorization rather than a single happy path.

Packaging is modern pyproject.toml with a legacy setup.py left in place

The build configuration is a setuptools project declared in pyproject.toml, with the version kept dynamic rather than hardcoded:

[build-system]
requires = ["setuptools>=61.0", "wheel"]
build-backend = "setuptools.build_meta"

Alongside it sits setup.py, and the file explains its own presence in a docstring: it is a legacy setup.py for backward compatibility, all configuration has been migrated to pyproject.toml, and the file is kept for compatibility with older tools. The body is correspondingly small, importing setup and calling it, with a comment noting that all configuration now lives in pyproject.toml:

from setuptools import setup

# All configuration is now in pyproject.toml
setup()

There is also a setup.cfg in the repository root and a tox.ini. The arrangement is the practical middle ground for a library with users on old packaging tooling: pip still works, but there is one source of truth for the metadata.

Python 3.9 is the floor and 3.14 is already listed

The supported range is spelled out in two places that agree with each other. The README states that only Python versions 3.9 and above are supported, and the project metadata declares the same constraint:

[project]
name = "pypresence"
dynamic = ["version"]
description = "Discord RPC client written in Python"
requires-python = ">=3.9"
license = "MIT"

The classifier list runs from Python 3.9 through 3.14, one entry per minor version, which tells you the author has been adding new interpreter versions as they appear. Two other classifiers describe the shape of the code: Framework :: AsyncIO and Typing :: Typed, alongside Development Status :: 5 - Production/Stable. Typing is worth noting for consumers, since a typed library with inline annotations gives editors something to work with. The asyncio classifier points at the async client usage rather than a blocking socket.

The contributor toolchain is pinned in a single optional extra

All development dependencies sit under one optional group named dev, which keeps them out of the install that end users receive:

[project.optional-dependencies]
dev = [
    "pytest>=7.0.0",
    "pytest-asyncio>=0.21.0",
    "pytest-mock>=3.10.0",
    "pytest-cov>=4.0.0",
    "black>=23.0.0",
    "flake8>=6.0.0",
    "mypy>=1.0.0",
    "isort>=5.12.0",
    "sphinx>=5.0.0",
    "sphinx-rtd-theme>=1.2.0",
]

The list reads like a standard Python quality stack: pytest with an asyncio plugin, a mocking plugin and coverage measurement on the test side, black, flake8, mypy and isort on the formatting and linting side, and Sphinx with the read the docs theme for building the documentation. The repository root confirms the shape of the project: a tests directory, a docs directory, a .github directory, a DEVELOPMENT.md that the README points to for setup instructions, testing, code quality tools and contribution guidelines, and a separate CONTRIBUTING.md.

The documentation site is the reference, the README is a signpost

This is the weakest part of the project as a public reference. The README is mostly badges, a licence badge, a star badge, links to the hosted documentation, a Discord support server, a Patreon link, and the note about Python versions. The actual reference lives at a GitHub Pages site, and the presence of a .nojekyll file at the repository root alongside the docs directory is consistent with that hosting choice. The README also links Discord's own Rich Presence documentation, Discord's RPC documentation, a pypresence support server and the general Discord API support server, which gives you somewhere to go when the hosted docs are not enough. The practical consequence for an evaluator is that you cannot judge the API surface from the README alone: the library directory is listed in the repository root but its contents are not described anywhere in the visible material.

MIT licence, three recent releases, and a slow release cadence

Licensing is unambiguous: the metadata declares license = "MIT", and a LICENSE file sits at the repository root, with the README badge pointing at it. MIT is permissive, so a project that vendors pypresence can ship it inside a larger application without extra obligations around source disclosure, though the licence text itself has to travel with the code. On the release side the repository has tagged versions v4.6.0 on 2025-10-15, v4.6.1 on 2025-10-17 and v4.6.2 on 2026-07-08, with the last push also dated 2026-07-08 and the repository not archived. The two October releases are two days apart, while the gap to the third is close to nine months. That pattern suggests bursts of work followed by quiet periods, so pin an exact version in your dependencies rather than tracking the branch.

Implementing the IPC client yourself is the alternative

The alternative approach is the one the README itself points at: Discord publishes its own Rich Presence documentation and its own RPC documentation, and a project could implement the client side directly against those documents instead of taking a dependency. The difference in approach is where the responsibility sits. With pypresence, the handshake, the payload conventions and the ready made example shapes come from the library, and you spend your time on your own application logic and on the authorized app setup. Hand rolling it means owning the connection lifecycle, the event handling and the ongoing updates yourself, with no library to file issues against. Since pypresence is a single MIT licensed package with a declared Python floor and a pinned release, taking the dependency is usually the smaller cost, but it does mean you accept a library whose last push was on 2026-07-08 rather than a protocol you implement once and own.

Editorial conclusion

pypresence fits developers who already have a Discord application id and want their tool to report status without writing an IPC client, and the examples folder makes the shapes easy to copy. It does not fit projects that need any Discord operation other than Rich Presence, because the README states that an authorized app is required for anything else, and it does not fit teams that want a stable, pinned release cadence, since the last push was on 2026-07-08 and the gap between v4.6.1 and v4.6.2 was close to nine months. Check your own client id and the license obligations of the MIT terms before writing the integration.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. qwertyquerty/pypresence on GitHub
4. README
5. Releases