| Commit message (Collapse) | Author | Age | Lines |
|---|
| | |
|
| |
|
|
|
|
|
| |
Turns out the MutableMapping class doesn't give us servicable
implementations of these, so we need to implement them ourselves.
Also, let's not have keys returned as bytestrings.
|
| | |
|
| |
|
|
|
| |
This is supposed to be provided by our MutableMapping mixin, but unit
tests are demonstrating that these don't really work as intended.
|
| |
|
|
|
|
| |
This would've been implemented by MutableMapping, but that
implementation is O(n) instead of O(1) since it just iterates the
entire hash and does HDEL. Feels wasteful.
|
| | |
|
| |
|
|
|
|
|
| |
The rest of the features should be provided by the MutableMapping abc
we're interfacing. Specifically, MutableMapping provides these:
.pop, .popitem, .clear, .update, .setdefault, __contains__, .keys,
.items, .values, .get, __eq__, and __ne__.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It was brought to my attention that we may need several caches per Cog
for some of our Cogs. This means that the original approach of having
this be a mixin is a little bit problematic.
Instead, RedisDict will be instantiated directly inside the class you
want it in. By leveraging __set_name__, we can create a namespace
containing both the class name and the variable name without the user
having to provide anything.
For example, if you create an attribute MyClass.cache = RedisDict(),
this will be using the redis namespace 'MyClass.cache.' before anything
you store in it.
With this approach, it is also possible to instantiate a RedisDict with
a custom namespace by simply passing it into the constructor.
- RedisDict("firedog") will create items with the 'firedog.your_item'
prefix.
- If there are multiple RedisDicts using the same namespace, an
underscore will be appended to the namespace, such that the second
RedisDict("firedog") will actually create items in the
'firedog_.your_item' namespace.
This is also possible to use outside of classes, so long as you provide
a custom namespace when you instantiate it.
Custom namespaces will always take precedence over automatic
'Class.attribute_name' ones.
|
| |
|
|
|
|
|
| |
We're using __init_subclass__ to initialize our RedisDict with the
subclass name as a namespace. This will be prefixed to all data that
we store, so that there won't be collisions between different
subclasses.
|
| |
|
|
| |
This is the module we will be using to interface with Redis.
|
| |
|
|
|
| |
This is almost hilariously easy since we can just use
the official image for it.
|
| |
|
| |
This probably isn't necessary anymore. We get so many new users that someone is going to DM us very soon when something breaks. We've outgrown this, and it just adds noise to the #verification channel in the form of pings.
|
| |
|
| |
The mentions alert that is sent out by the Verification cog currently pings `@everyone` despite being quite unactionable by most people receiving the ping. As it happens frequently, especially with the recent uptick in joins, I'm removing that ping to not bother our moderators as much.
|
| |\
| |
| | |
Python News implemention
|
| | |\
| |/
|/| |
|
| | | |
|
| |\ \
| | |
| | |
| | |
| | | |
python-discord/feature/hemlock/perma-ban-override-temp
Perma Bans now Overwrite Temp Bans
|
| | |\ \
| |/ /
|/| | |
|
| |\ \ \
| | | |
| | | | |
Add remindme alias for the remind command
|
| |/ / / |
|
| |\ \ \
| | | |
| | | | |
Remove the mention command and configuration settings for it
|
| | |\ \ \
| |/ / /
|/| | | |
|
| |\ \ \ \
| | | | |
| | | | | |
Use selector event loop on Windows
|
| | |\ \ \ \
| |/ / / /
|/| | | | |
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
python-discord/bug/backend/911/log-listener-exceptions
Log unhandled errors from event listeners
|
| | |\ \ \ \ \
| |/ / / / /
|/| | | | | |
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | | |
Update to Antimalware Filter (.txt uploads)
|
| | |\ \ \ \ \ \
| |/ / / / / /
|/| | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
than 2000 chars
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
longer than 2000 characters
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
longer than 2000 characters
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
By default, discord.py prints them to stderr. To better help detect such
errors in production, they should instead be logged with an appropriate
log level. Some sentry metadata has also been included.
`on_error` doesn't work as a listener in a cog so it's been put in the
Bot subclass.
Fixes #911
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
`BaseTransport.close()` is not a coroutine and therefore should not
be awaited.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
aiodns requires the selector event loop for asyncio. In Python 3.8,
the default event loop for Windows was changed to proactor. To fix this,
the event loop is explicitly set to selector.
|
| | | | | | | | |
|
| | |_|_|/ / /
|/| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
It was made obsolete by a new Discord feature. Users can be granted a
permission to mention a role despite the role being set as
non-mentionable.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Another refactor/cleaning to make the logic clearer and easier to understand. Also cleaned up the trace logs to be shorter and more concise. Thanks, @scragly!
Co-authored-by: scragly <[email protected]>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
- Refined the logic for `apply_ban()` even further to be cleaner. (Thanks, @MarkKoz!)
Signed-off-by: Daniel Brown <[email protected]>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
- Changed docstring explanation and function name of `get_active_infractions` to `get_active_infraction()` to better convey that only one infraction is returned. Also changed all relevant uses to reflect that change.
- Added explanation of parameter `send_msg` to the doc strings of `pardon_infraction()` and `get_active_infraction()`
- Adjusted placement of `log.trace()` in `pardon_infraction()`
- Adjusted logic in `apply_ban()` to remove redundant check.
- Adjusted logic in `apply_ban()` to be consistent with other checks.
Signed-off-by: Daniel Brown <[email protected]>
|
| | | | | |\ \
| |_|_|_|/ /
|/| | | | | |
|
| |\ \ \ \ \ \
| |/ / / / /
|/| | | | | |
Display animated avatars in the user info command
|
| | | | | | | |
|
| |/ / / / /
| | | | |
| | | | |
| | | | | |
Fixes #914
|
| | |_|/ /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
- Changed `has_active_infraction` to `get_active_infractions` in order to add additional logic in `apply_ban`.
- Added `send_msg` parameters to `pardon_infraction` and `get_active_infractions` so that multi-step checks and actions don't need to send additional messages unless told to do so.
Signed-off-by: Daniel Brown <[email protected]>
|
| |/ / /
| | |
| | |
| | | |
help channel
|
| |\ \ \
| | | |
| | | | |
Sort help channels and add support for `how-to-get-help` channel
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
As we want to add an "informational" channel to the `Python Help: Available` category, we need to make sure that the Help Channel System ignores that channel.
To do that, I've added an `is_excluded_channel` staticmethod that returns `True` if a channel is not a TextChannel or if it's in a special EXCLUDED_CHANNELS constant. This method is then used in the method that yields help channels from a category and in the `on_message` event listener that determines if a channel should be moved from `Available` to `Occupied`.
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This commit reintroduces bottom sorting for help channels during a category move, but in a more reliable way that also causes far fewer "channel list glitches". This is accomplished by using the "bulk channels update" endpoint of the Discord API.
-----------
The Problem
-----------
Discord's positioning system is not that easy to work with for developers: Instead of having separate pools of position integers for each category, all text channels are considered to be part of the same "position pool" (or "bucket" in discord.py terms). This also means that changing the position integer of one channel may cause the position integer of another to change, regardless of if the channels share a category or even of if they are close to each other in the guild. As clients receive the position update for each channel as separate CHANNEL UPDATE events, this means that moving one channel may cause other channels to (temporarily) jump around as the client receives the EVENTS from the API. As some position changes affect all the channels in the guild, this will also trigger a nice "channel wave" rolling down the channel list from time to time.
For our use case, this was exacerbated by the way `discord.py` handles position changes: It will enumerate the entire, sorted channel list whenever a position change occurs and send a "bulk request" with updated position integers for the entire guild to Discord. This was the reason that all of the sorting methods we've tried resulted in a lot of those "wave" glitches as clients would get a lot of CHANNEL UPDATE events. In addition, the way `discord.py` inserted channels into the payload also meant that our "high integer" methods did not work reliably.
------------
The Solution
------------
Fortunately, there is a solution that will work well most of the time: Making a `bulk channels update` request with only channels of the category we're currently interested in. By providing the current position of the channels that are already in the category, combined with the correct position of the channel moving into the category, we effectively "lock in" the existing channels at the location they already have. The new channel is simply moved into the right position in relation to the existing channels.
This means that effectively, we only communicate one channel position change to Discord, making sure that as few channels as possible actually change their formal "position int".
From there on, there are two options:
1. Keep the existing channels in place, add the new channel at the bottom (new highest int)
2. Keep the existing channels in place, add the new channel at the top (new lowest int)
Both methods work, but option two has a flaw: The position int will get smaller and smaller, until it reaches `0`. Since negative position integers are not allowed, the entire category now has to be shifted upwards to make room for new top channels. This comes at the cost of a "wave" glitch within the category. My initial instinct was to solve this by giving the channels in the category a "really high" straight of position ints, but as Discord recalculates the ints from time to time anyway, this does not work.
That's why I opted for the `bottom sort` option, which does not suffer from that issue. I've also asked the question of `top` vs `bottom` in #admins, without the context above, and the preferred method seemed to be `bottom` in any case.
-----------
Limitations
-----------
While Discord doesn't care that much about duplicates or neatly ascending integers, some channel move actions will inevitably result in a recalculation of the positions ints. This means that "wave" glitches may still happen from time to time, but they should be infrequent. (They also happen if you drag channels in your client; it seems to be a fundamental part of how positioning works.) I think this is something we'll have to live with.
Another thing that I suspect may happen is that during times of API lag in the middle of help channel rush hour, some CHANNEL UPDATE events belonging to previous channel moves will not be received/processed yet by the time we make the next move. As we rely on cached position integers, this could mean that from time to time a channel is inserted near the bottom but not at the bottom. As Discord sends these CHANNEL UPDATE replies as individual events in an asynchronous manner instead of as a single response to our `bulk channels update` request, there's nothing much we can do about this. However, I have yet to observe this, so maybe it will never happen.
|
| |\ \ \
| | | |
| | | | |
Allowing `!eval` in help channels
|
Leon Sandøy
Leon Sandøy
Sebastiaan Zeeff
Sebastiaan Zeeff
S. Co1
Daniel Brown
Suhail
Savant-Dev
MarkKoz
kwzrd
Joseph Banks