discatpy-archive / library Goto Github PK
View Code? Open in Web Editor NEWA high level, asynchronous Discord API wrapper made completely from scratch.
License: MIT License
A high level, asynchronous Discord API wrapper made completely from scratch.
License: MIT License
This issue will track the coverage of Discord API models.
If you would like to contribute and you want to know how models are defined, check out the pre-existing models in discatpy.models
!
Unlike Gateway Interactions which just require connecting to the Gateway as usual and receiving the INTERACTION
event, HTTP Interactions will require a little more work however.
Overview of the Feature Request
Rewrite the generate endpoints script, renaming it to generate_routes.py
, rename the data/endpoints
folder to data/routes
, and change the type of the files used in data/routes
from JSON to TOML.
What is this Feature Request for?
DisCatCore
The Problem
The generate endpoints script needs a good code scrub. There are some things that could be done better or just completely removed, like the function generator's generate
method. Also the function generator's methods for managing arguments can be removed in favor of the publicly available list of args. There might be more, and they'll be seen in my PR.
Now to the name changes. Since the beginning of the endpoint generator, I thought that the name "endpoint" sounded more appropriate and did not consider the name "route" at all. The name "route" is used for the HTTP client to specify the metadata about a Discord API route. It makes more sense to name our endpoint generate a route generator since the route wrappers generated wrap Discord API routes (obviously).
Finally, the file change. JSON is unreadable for our purposes.. TOML would be a better format, since it's designed to be a config file format and human readable.
The Solution
Here's what a new route file under TOML will look like:
name = "UserRoutes"
requires = ["typing", "discord_typings"]
[get_current_user]
method = "GET"
url = "/users/@me"
[get_user]
method = "GET"
url.link = "/users/{user_id}"
url.parameters = [{name = "user_id", type = "dt.Snowflake"}]
[modify_current_user]
method = "PATCH"
url = "/users/@me"
json.parameters = [
{name = "username", type = "UnsetOr[str]", default = "Unset"},
{name = "avatar", type = "UnsetOr[t.Optional[str]]", default = "Unset"},
]
[get_current_user_guilds]
method = "GET"
url.link = "/users/@me/guilds"
url.parameters = [
{name = "before", type = "UnsetOr[dt.Snowflake]", default = "Unset"},
{name = "after", type = "UnsetOr[dt.Snowflake]", default = "Unset"},
{name = "limit", type = "int", default = "200"},
]
Current Solution
N/A
Additional context
N/A
Currently, there is no way to pass init parameters that the Gateway & HTTP clients from DisCatCore support via discatpy.Bot
. This is not a good thing because customization is an important thing to offer.
One solution I have in mind is to make a special data class that sort of acts like a wrapper for passing arguments into the Gateway & HTTP clients. Some important values like token
or intents
will be left out of these data classes because those are more important parameters than the rest of the parameters the Gateway & HTTP clients support.
Overview of the Feature Request
Migrate DisCatCore & DisCatPy to PDM.
What is this Feature Request for?
DisCatCore & DisCatPy
The Problem
Poetry doesn't have a lot of tools & customization compared to PDM. PDM has built-in dynamic version management and build hooks that can make automation easier. Plus, although this doesn't technically matter, PDM supports PEP 621 style metadata, while Poetry doesn't.
The Solution
N/A
Current Solution
N/A
Additional context
discatpy-archive/core#34 was my implementation of this with DisCatCore. Some of the aspects, like the CI, can be migrated directly from this.
Currently, the DisCatPy API design is all over the place. It's just a glob of files into one big source folder. Instead, it would be more ideal if the major parts of the API are split into individual folders inside of this source folder.
In progress via the api-refactor
branch.
Overview of the Feature Request
Make a better logo for DisBotPy
What is this Feature Request for?
The repository
The Problem
The logo right now is too long for some portions of where the logo could be used. And it's also not the best logo and could be redesigned.
The Solution
Make a smaller logo, preferably one that is 512x512 for the Discord server.
Additional context
What should be done:
Describe the Bug
abs.py
file contains abstract base classes and should be named abc.py
. "abs" usually means "absolute" and will likely confuse future contributors.
Reproduction Steps
ls
Expected Behavior
A clear and meaningful name for file
Actual Behavior
File name which will likely cause misunderstandings
Traceback Error
N/A
System Information
N/A
Additional Context
N/A
Port discatpy-archive/core#27 to the monorepo.
Pretty straightforward. Depends on #8.
The reason for doing this is that DisCatPy itself is a more higher level Discord API wrapper but it has a core API that's accessible to users. It would make more sense if they were split. DisCatCore would be the name of the lower level API and the higher level API would keep its current name, DisCatPy.
This will most likely be done when I make a separate organization for DisCatPy.
Overview of the Feature Request
Bump the Python version minimum from 3.8 to 3.9.
What is this Feature Request for?
The whole library
The Problem
Currently, we are using type alias like Dict
or List
from the typing module. However, in PEP 585 these type alias were deprecated for their builtin counterparts. This PEP unfortunately was not implemented in Python 3.8 but 3.9.
The Solution
Bump the Python version minimum in setup.py
(pyproject.toml
for the API redesign) from 3.8 to 3.9.
Current Solution
Since it's only deprecated and not removed entirely in 3.9, keeping it wouldn't really affect anything. But if it is going to be removed soon, then it's better to be prepared now then later.
One solution I came up with to circumvent this is to redefine these type aliases to either be their builtin counterparts or to be the type alias from the typing module. However, this does seem unnecessary. Another solution is to use the new stringized annotations feature (from __future__ import annotations
) in every module.
Additional context
N/A
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.