CodeQL minor nitpick pass

[dgw]

Description

For #2381 I made sure we wouldn't introduce any Error-level alerts, because those would have given the master branch a ❌ check status. Anything below that level (that wasn't a false-positive or a test case) was mostly left alone.

This PR's branch name, useless-code, is inspired by the alert label that caught my eye first. At time of opening that label also applies to most of the alerts that will be fixed by this patch.

Checklist

• I have read CONTRIBUTING.md
• I can and do license this contribution under the EFLv2
• No issues are reported by make qa (runs make quality and make test)
  • I managed to break my flake8 somehow, but these tweaks are so minor I did not waste time trying to fix it just for this PR
• I have tested the functionality of the things this change touches

[SnoopJ]

Changes look fine to me. The commit message for 0b50255 should probably reference the CodeQL rule that it's fixing but you may plan to squash those references away anyhow.

I would like to formally declare my annoyance with CodeQL's py/import-and-import-from rule which looks more like someone's personal aesthetics than a serious concern about maintenance (what's the alternative supposed to be, import foo; # other imports; something = foo.something ?!)

[dgw]

The commit message for 0b50255 should probably reference the CodeQL rule that it's fixing

Yeah, I forgot that one, whoops. Fixed.

I would like to formally declare my annoyance with CodeQL's py/import-and-import-from rule which looks more like someone's personal aesthetics than a serious concern about maintenance (what's the alternative supposed to be, import foo; # other imports; something = foo.something ?!)

The alternative is supposed to be just using foo.something with the namespace, in your example case.

I personally agree with the idea that things should be imported either under a module namespace or individually, but not both. As a contrived demo, I think it would be silly to from sopel import plugin and then also from sopel.plugin import commands, and I think it would lead to potential confusion later.

But I also don't like importing individual module members in most cases anyway. I've found that the best way to have future-proof imports is always importing a (sub)module, and using that module's members as members (. notation). Then you 1) always know where something came from, because the module it's from is always included at the site of use; and 2) you can use other features of the module without modifying imports.

Because of (1) above, I also tend to avoid using import ____ as, except to avoid name collisions.