-
-
Notifications
You must be signed in to change notification settings - Fork 402
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
privileges, plugin, tools.target, docs: channel privileges as IntFlag #2540
Conversation
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.
I'd rather have the docstring kept at the module level, however this is in no way a blocker for me, as both version works for me. Also a nitpick that isn't important either.
Aside from that, I really like the idea of the ENUM!
I figure getting "rewrite sopel/privileges.py (97%)" is the most justified I'll ever be in my life for adding a copyright comment. :D
The history and brief overview of how IRC privileges work is not part of the module/class documentation. It's more appropriate to explain in the doc page about privileges as a general concept.
Super-duper deemphasized that privileges are integer values. Removed the actual values from code examples, to show logic only. Condensed admonitions about nonstandard privilege levels/modes into a single location, with cross-references.
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.
Looks great
Description
Rather than have someone open an issue, I decided to Just Do It. I realized that the time to change how these constants are defined/accessed is now, as they've been moved to a new location but the new location hasn't appeared in a release yet. After we release 8.0, it would be that much more painful to change this a second time.
I'm open to bikeshedding on the class name here. If nothing else, maybe it should be plural to match
sopel.formatting.colors
. I'm keeping in mind the fact that we keep thinking about better access controls on bot functions, and other stuff that might also logically have constants living insopel.privileges
.AccessLevel
is perhaps not the most future-proof choice for avoiding ambiguity. Other ideas included just plainLevel
,Channel
,ChannelPrivilege
,ChanPriv
, and a few more I forgot.If we do this, the type annotation changes in
plugin
will resolve #2538. Decorators that take this type will link to it in their function signatures' type annotations:Checklist
make qa
(runsmake lint
andmake test
)Notes
Honestly,
privileges.Channel
made the most sense to me as far as a future collection of different kinds of privileges went. Having two different types namedChannel
—here, and intools.target
—sounds like a terrible idea in the long term, though.tools.target.Channel
even has logic to manipulate the hypotheticalprivileges.Channel
type. Getting into "wait, which kind ofChannel
is this?" sounded very not-fun.