- API Reference
- Frequently Asked Questions
- discord.py is dead! Will this library die too?
- Are you going to/will/consider fork(ing) discord.py?
- Will discord.py be able to work with this library?
- Where should we go with discord.py being gone?
- Why are you not supporting cooldowns?
- Will we not be able to create message commands?
- I’m getting “
AttributeError: HTTPClient not found!” when I try to execute helper methods!
- Context and Messages don’t have the
- My question is not answered on here!
Ever since December 2019, this open-source project has become the culmination of dedication and research towards figuring out the best way to bring interactions from Discord to you: we are an easy, simple, scalable and modular library for Discord interactions.
Tired of using numerous module dependencies for slash commands and buttons?
Looking for a compatible library that implements all interactions?
Itching to get your hands on slash commands, but in a simple manner?
Look no more! The goal of this library is to make all three of these questions go from possibilites to trivial matters.
What can we do?¶
Our library—inside and out, offers numerous benefits and presents itself as a worthy module in your bot’s dependencies:
The base features of our library, built with our API include:
Dynamic object data generation: all event data dispatched from the Gateway is dynamically transformed and generated into two-way serializable JSON objects.
Sane rate limiting: our HTTP client implements pre-emptive rate limit avoidance, so your bot is guaranteed to never hit HTTP
On-demand cache: every HTTP request and Gateway event made is cached when needed, so you never have to save information yourself.
Simplified data models: every object presented is accessible as either a raw dictionary/
application/jsonor list of recursive attributes.
Some more unique features that are exclusive to our interactions include:
Event-triggered callbacks: whether a component, application command or interaction response, you’ll never need to worry about bridging responses.
Dual-way decorator logic: a decorator can act as both a constructor for an interaction, as well as a callback.
API-strict naming: no more confusion with the naming approach of many libraries; we follow the naming style of interactions from the officially curated Discord Developers documentation.
Extensive framework structure: build your own tools and technologies for our library to develop and integrate community creations.
What do we not offer?¶
While we certainly offer a lot of benefits, we unfortunately have our own downsides:
This list is subject to change as time goes on: some of these items may be added to the core of the library in the future.
No native cooldown decorator/method.
Lack of automatic sharding and voice clients.
Where do I start?¶
Please look at our pages below to find out where to go.
How can I contribute?¶
This open-source project utilizes the following workflows for development:
2.16.0: the architecture uses this before every commit to format and check for severity/QOL-breaking changes.
4.1.2: all of our documentation is powered off of autogenerated documentation of the Sphinx engine.
0.4.4: our internal logger uses a customized coloring formatter to make looking for specific conditions easier when running tests.
1.0.0: every commit that we make to our branches use the official specification of CC 1.0.0 to make git graphs easier when improving and refining communication between code reviews, Pull Requests and commits.
When can I start?¶
We also have some extra ground rules about making any specific contributions involving:
We do not accept abstraction-based requests. (e.g.
A request has to be approved by at least one developer.
You must be willing to change/adhere to reviews from participants where necessary.