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 in sopel.privileges. AccessLevel is perhaps not the most future-proof choice for avoiding ambiguity. Other ideas included just plain Level, 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:
[x] I can and do license this contribution under the EFLv2
[x] No issues are reported by make qa (runs make lint and make test)
Thank you @SnoopJ for #2469 and also teaching me how to use it this week.
[x] I have tested the functionality of the things this change touches
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 named Channel—here, and in tools.target—sounds like a terrible idea in the long term, though. tools.target.Channel even has logic to manipulate the hypothetical privileges.Channel type. Getting into "wait, which kind of Channel is this?" sounded very not-fun.
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.AccessLevelis 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
pluginwill resolve #2538. Decorators that take this type will link to it in their function signatures' type annotations:Checklist
make qa(runsmake lintandmake test)Notes
Honestly,
privileges.Channelmade 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.Channeleven has logic to manipulate the hypotheticalprivileges.Channeltype. Getting into "wait, which kind ofChannelis this?" sounded very not-fun.