Closed half-duplex closed 6 months ago
Also, given the format, should this
__str__()
and that for Rule and Command be__repr__()
?
It seems to me that the __str__()
implemented here could probably be worked into a __repr__()
and the log line could be changed to use %r
. Might simplify the logic a bit.
I like the idea. For now the rules have a __str__
but that's probably not what we actually want, and __repr__
could be it.
@Exirel @SnoopJ This seems like a no-brainer for 8.0.0 to me, so its logs are intelligible. We can look at switching the relevant bits to __repr__()
in 8.0.1 or 8.1. Any objections?
<+xrl> Not a big fan of the lack of tests in #2569
Well now it has test coverage. I stopped short of hard-coding the exact log message format, but it's enough to make sure that the main concern will be caught:
<+xrl> Yes. Because it is used in the code somewhere and one day it may raise an exception because something changed
with unexpected consequences.
<+xrl> Happened to me a lot. `__str__` looks innocuous, but it isn't.
Description
When Sopel is started with loglevel DEBUG, it currently outputs a stack of lines like this:
The str(cap_req) gives no useful information. This PR adds
capability.__str__()
so it does:Open to format opinions.
Also, given the format, should this
__str__()
and that for Rule and Command be__repr__()
?Checklist
make qa
(runsmake lint
andmake test
)