interactions.py
interactions.py copied to clipboard
interactions-py
feat: add ext.load and a_load
Pull Request Type
- [x] Feature addition
- [ ] Bugfix
- [ ] Documentation update
- [ ] Code refactor
- [ ] Tests improvement
- [ ] CI/CD pipeline enhancement
- [ ] Other: [Replace with a description]
Description
Adds ext.load and a_load methods for loading hooks
Changes
Related Issues
Test Scenarios
from interactions import Extension
class TestExt(Extension):
def load(self, *args, **kwargs):
print("Test extension hooked!")
async def a_load(self, *args, **kwargs):
print("Test extension async hooked!")
Python Compatibility
- [ ] I've ensured my code works on Python
3.10.x - [x] I've ensured my code works on Python
3.11.x
Checklist
- [x] I've run the
pre-commitcode linter over all edited files - [x] I've tested my changes on supported Python versions
- [ ] I've added tests for my code, if applicable
- [ ] I've updated / added documentation, where applicable
Codecov Report
Patch coverage: 33.33% and project coverage change: +0.04% :tada:
Comparison is base (
3802f74) 58.13% compared to head (c80222c) 58.18%.
:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@ Coverage Diff @@
## unstable #1509 +/- ##
============================================
+ Coverage 58.13% 58.18% +0.04%
============================================
Files 143 143
Lines 15329 15338 +9
============================================
+ Hits 8912 8924 +12
+ Misses 6417 6414 -3
| Files Changed | Coverage Δ | |
|---|---|---|
| interactions/models/internal/extension.py | 36.69% <33.33%> (-0.24%) |
:arrow_down: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
@AstreaTSS
Why does load even need to exist when init quite literally does the same thing?
Completeness, and accounting for the fact people seem adverse to using __init__. Fully agree, it's a layer of separation without much gain, but its more intuitive for the aforementioned - ux takes priority even if redundant
Why is a_load called a_load instead of something more intuitive like async_load?
I actually went back and forth on this, i landed on a_load for shortness but im really not married to it. If anything i dont even like the load phrasing. in retrospect async_load will be fine
What's the point of using a_load if it only runs in certain situations? Most people are going to use it thinking it's a solution to using load_extension before the event loop exists, when it really doesn't work like that. I'm guessing what you intend for users to do is (somewhat awkwardly) use both async_start and a_load?
Your assertion here is weird, but I'll focus on the premise instead. I toyed without putting handling it under the same paradigm as a async_start - which is basically a psuedo listener, however async_start had backlash with its "cheating the event loop" by allowing you to queue without an event loop being created. If you need the asynchronous load call, you should be loading the extension from a coroutine - ie asyncio.run(start_bot) where start bot instantiates and loads extensions
If deemed preferable, I can mirror async_starts behavior, but either way someone is going to be grumpy.
If anything i dont even like the
loadphrasing.
Agreed, can we name it eat or consume? I like snake terms instead, keep it 'hip.
Completeness, and accounting for the fact people seem adverse to using
__init__.
Is... this actually a thing? Genuinely asking - I've never encountered a person who didn't want to do it, especially since discord.py does the same.
async_starthad backlash with its "cheating the event loop" by allowing you to queue without an event loop being created.
I'm going to be frank with you - the only people who care are a bit too much into asynchronous programming. For most users that just don't care, not making it queue-esque will make it not helpful.
If you need the asynchronous load call, you should be loading the extension from a coroutine - ie
asyncio.run(start_bot)where start bot instantiates and loads extensions
Fully agree here, but users seem to be adverse to that.
I'm going to be frank with you - the only people who care are a bit too much into asynchronous programming. For most users that just don't care, not making it queue-esque will make it not helpful.
As one of those people who "care a bit too much," I'm going to have to side with that consensus. I didn't really understand how important it was until after I started working with async call sites in lower level languages, it's absolutely crucial for us to respect the event loop for scheduling. I prefer us keeping a sane guideline for schedulers over convenience, we can always write facade layers to nicely interface with the async logic we write.
It... does respect the event loop though. It's not a violation, it's simply a convenient queue. I understand lower-level languages make it important, but this is Python out of all things.
PR reverted to draft - either way changes are required.
async_start does not respect the event loop, that's not up for dbate - but that's user-friendliness I added for the sake of helping people newer to async programming.
Under the same ethos, I will update this to do the same
Just to note, apparently Callable dislikes passing ellipsis as the return type, (pytest results) we could make the param spec the ellipsis and change return to Any, but this may violate our MyPy config
Proposing this PR to be closed for being stale, continued interest should lead to a new branch/PR being set forth
