* Easily use multiple prefixes... Now onto programmatic fetching and conquering the world!
* Updated a test and added some documentation.
Now someone just needs to find a way to transition into multiple prefixes...
* Allow bots to be run without access to the console.
This is going to allow for custom prefix-getters :D
* Fix flake8's innate hate of monkey patching.
* Documentation!
No idea how to make tests for this...
* Python 2 compatibility is basically impossible.
Implicit Relative Imports ruin the day here (`import logging`) and so why not ruin Python 2's day with type hinting?
* And it's done!
Python 2 **can** keep using disco, because `disco.util.runner`
shouldn't be automatically imported.
Changelog:
+ Added two keys to the config.
`commands_prefix_getter`
`commands_prefix`
+ Added documentation.
+ Added a new utility file, `disco.util.runner`
* nekoka.tt code review (github.com/nekocatt)
Some of the stuff edited (`disco.util.config.Config`) are not within the scope of this PR, but `disco.util.runner.create_bot` makes it easier to mess up.
(also, if lines 414 to 417 are premature optimization, that's all me)
* Undo the change to `disco.util.config.Config`.
There is probably a way to do this, but that's topic of a different PR.
* remove unused import
* Python 2 Compatibility
* Move `disco.util.runner.py` to another PR
* b1nzy code review
* fix tests
* stop being dumb
* Remove unintuitive behaviour.
Previously, if you had `{@mention} {prefix}{command}`, `require_mention` was set to `True`, and `prefixes` were set to anything, then the command framework would look for a command named `{prefix}{command}`. However, this specific grouping of settings would not be chosen unless the bot creator wanted the command framework to look for `{command}`.
tl;dr settings weren't being respected
Co-authored-by: Andrei Zbikowski <[email protected]>
This will not undergo a regualar deprecation cycle since the schedule
provided by discord (see discordapp/discord-api-docs#967) is less than
the amount of time it would take to fully deprecate this field. Instead
we will just consider this a v1 breaking change.
Clients on previous versions should continue to work regardless of
Discord's planned changes for this field, although the data provided
from the field may be invalid or empty.
Discord is inconsistent here and doesn't emit a VoiceStateUpdate for the
old session_id when a user connects to voice from a different device
(thus disconnecting the first device). To avoid corrupting our voice
state cache, we need to remove any of the users old sessions (they
should have at most one).
I included tests on this one because its esoteric and undocumented, so
there is a high chance I'll break it in the future.
Previously under python 2.x the text field allowed through values which
would not be turned into a string. This is invalid as all output should
be a valid textual string. This commit fixes that behavior to properly
cast the value to a string in all cases.
Previously we used None as the sentinel for determining that a user had
not specified a default value for a field. This meant that a user could
never select `None` as the default value. We now properly use UNSET to
determine if a default was passed, this aligns better with the code as
it stands given that if no default is passed we'll use UNSET anyway.
This commit is a fairly large chunk of code that fixes a previously
annoying and nasty bug causing cached_properties to not be cleared.
Alongside this bug fix I took the opportunity to refactor the entire
methdology behind cached properties, and bind them more strictly to the
behavior of models.
Prior to this commit, cached_properties where not be properly reset upon
a model's `update` method being called due to some invalid code. Along
with this issue, the actual behavior of cached properties landed in a
weird in-between/gray area where they had to support both non-model and
model use cases.
The new version of cached_property is strictly for use with models, and
another version `simple_cached_property` was added to support other use
cases. The new cached_property simply builds an actual `property` within
the metaclass. This is fairly efficient, and also reduces the surface
area of behavior.
When writing this I messed around with a few ideas, including allowing
the user of `cached_property` to define a linkage between the property
and fields that should invalidate its cached value, but this was both
messy and introduced massive cognitive load on understand when a
cached_property should be cleared. Although this version is slighty less
efficient, I'm very much in favor of it vs the alternatives I tried.
UserDict was the wrong way to achieve this, modern versions of Python
can just subclass dict. This provides an immense performance boost by
allowing getitem/setitem calls to be routed directly to the underlying
storage within cpython land, instead of having to route through the
items MRO and eventually hit __dict__
This would cause our GatewayClient to get rate limited when guild member
syncing was enabled for clients with a large number of guilds. The bug
had to do with the limiter releaseing all the requests after the initial
period it blocked for. This was resolved by rewriting the SimpleLimiter
to use a semaphore.
1. The shortest possible match for a single command was an empty string.
2. Group matching was overly greedy, and would allow extraneous
characters at the end of the group match.
For some reason when I initially built disco I made these types binary.
They are not binary. They are ascii hash-strings. So lets make them
strings. This fixes the Python 3 oddities described in #29 related to
formatting byte strings into normal strings.
- Remove the limitation that prevented us from surpassing 100 commands
- Fix CommandEvent.name being the full command string, and not just the
command name
- Fix the error thrown on mismatched args being utter trash
EXPLOSION
Andrei
Andrei Zbikowski