~25 classes duplicate self.logger = logging.getLogger(...) instead of a shared helper

[Rushaway]

Part of #147

Finding

self.logger = logging.getLogger(self.__class__.__name__) is copy-pasted into the __init__ of 25+ classes (e.g. Config.py:14, Player.py:15, Commands.py:50, CommandHandler.py:25, ClientProtocol.py:12, AsyncClient.py:20, SourceRCONClient.py:22, PlayerManager.py:20, and many more).

Why it matters

Purely mechanical duplication with no functional issue today, but any future change to the logger-naming convention (e.g. adding a module prefix) requires touching every one of these files individually.

Suggested fix

A small LoggerMixin (or a module-level get_logger(obj) helper) would remove ~25 identical lines and centralize the convention.

🤖 Generated with Claude Code

[Rushaway]

Closing this one as not worth doing in the form it describes — I looked into implementing it and the cure is worse than the disease.

What I found

A LoggerMixin doesn't actually fit. Of the ~20 files carrying self.logger = logging.getLogger(self.__class__.__name__), only 2 (Commands.py, Subscribe.py) call super().__init__() at all. A mixin that assigns self.logger in __init__ would require adding cooperative super().__init__() calls across the rest — more churn, and more subtle failure modes, than the single line it removes. Several of these classes also already have a base (BaseCommand subclasses, and ConfigFile subclasses as of #165), so this would mean multiple inheritance to save one line.

The alternative — Utils.get_logger(self) — is a net wash. One line becomes one line, except now it's a project-specific indirection instead of the standard Python idiom every contributor already recognizes.

The stated benefit is speculative. "If the naming convention changes you'd touch every file" — but nothing indicates we want to change it, and self.__class__.__name__ already adapts per class on its own.

Practical timing argument: 11 of these files are touched by the currently-open PRs from this batch (#160–#170). A 22-file sweep would conflict with nearly all of them, for close to zero benefit.

What would actually be worth doing

If the goal is better logging ergonomics, the valuable change isn't deduplication — it's hierarchical logger names. Right now names are flat (AudioManager, FFmpegAudioPlayer), so they don't nest under a common root and you can't configure them as a group. Switching to torchlight.AudioManager etc. would let an operator do:

logging.getLogger("torchlight.FFmpegAudioPlayer").setLevel(logging.DEBUG)

and set levels per subtree.

That's a genuinely useful improvement, but it's an operator-visible behavior change (log output changes; anything filtering on the current flat names breaks), not the mechanical dedup this issue describes. Happy to open that as its own issue if it sounds worthwhile — just say so.

🤖 Generated with Claude Code