The prior changes to use of return in finally (#9981) are now
insufficient. Without disclosing their intent when raising the issue,
this was used by them as part of justifying a SyntaxError for working
code outside of the normal process for adding errors, and with it
presenting to end users in a way that breaks downstream user's existing CI
While making the change, I've continued to not log errors like
CancellationError or TimeoutError to users here by default, as it is not an error
they need to be aware of during shutdown given the limited kinds of
BaseException that could raise in this context, see: #9984 for prior
analysis. I've added a debug log should anyone want access to this kind
of failure while debugging gateway close, but due to how asyncio
shutdown happens, this is unlikely to ever log anything useful even in a
library debugging context.
Every thread now has a name and either a contextually relevant
identifier or their in hex to disambiguate multiple threads of the same
type. Also finally gets rid of that old python 2 style init call.
As it is a required parameter.
Don't unnecessarily send a second SPEAKING payload after
connecting to voice
We do need to send a SPEAKING payload in order to set our SSRC value
after connecting to voice, yet that can be with a `state` of 0
(SpeakingState.none).
There is no reason to send 2 packets; one marking ourselves as
speaking, and then not speaking.
Some of the logs were only useful for debug scenarios, so they have
been downgraded to DEBUG. Others were in INFO but supposed to be in
WARNING so those were upgraded.
Segments where readability was hampered were fixed by appropriate
format skipping directives. New code should hopefully be black
compatible. The moment they remove the -S option is probably the moment
I stop using black though.
The difference in speed seems negligible at start up, which is when
most time is taken for actually parsing JSON. I could potentially be
missing something but profiling didn't point to any discernable
difference.