-
Notifications
You must be signed in to change notification settings - Fork 5.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update Filters, CommandHandler and MessageHandler #1221
Conversation
Makes it possible to have filters work on an update instead of message, while keeping behavior for current filters
- remove allow_edited (deprecated for a while) - set deprecated defaults to None - Raise deprecation warning when they're used - add sensible defaults for filters. - rework tests
- rename update_types -> updates - added some clarification to docstrings
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While I do think that this change is overall good, it does introduce quite a lot of complexity to the user that wasn't there before (kwargs are easier to understand than negating filters imo). Therefore we need to be really sure that our docs are good.
That said, I think it mostly looks good. Mostly nitpicks :)
Makes it possible to have filters work on an update instead of message, while keeping behavior for current filters
- remove allow_edited (deprecated for a while) - set deprecated defaults to None - Raise deprecation warning when they're used - add sensible defaults for filters. - rework tests
- rename update_types -> updates - added some clarification to docstrings
Can't figure out how to get it to build on CI. Guess we will see when we merge onto v12 and then PR v12 onto pmaster |
Might wanna remove the v12 from travis again. Though I wonder if the reason its not working is because of case sensitivity? |
Ok, The last thing we need to decide IMO is what to do with
I prefer the second option. |
I agree with you here. Also I suggest to keep RegexHandler as a wrapper over the new MessageHandler. |
after discussing the concept of the wrapper in the developers group I now understand that:
As of the above I change my mind on the subject of wrappers and suggest that we don't add |
I agree with that 👍 |
Now returns a list of match objects for every regexfilter
And raise deprecationWarning on creation
- use data_filter instead of regex_filter on BaseFilter - have these filters return a dict that is then updated onto CallbackContext instead of using a list is before - Add a .match property on CallbackContext that returns .matches[0] or None
Gave another lookover, merging with the intention of releasing a V12 beta to squash bugs. |
See #1117 for discussion