Fixing typing for ListenerMixin.listener

[aericson]

Description

This PR addresses #2375. The typing of that method is a bit complex because it has two different code paths which result in different typing of parameters and return.

I've added two overloads so that we get better type checking.

Alternative solutions

I've also considered another way to go around this by separating listener into two methods which should reduce complexity but in this PR I only addressed the typing.

Here is how the alternative solution could look like:
https://gist.github.com/aericson/d36514eb45b9ec1f65b8ee51fdf5c08f

[ahopkins]

I've also considered another way to go around this by separating listener into two methods which should reduce complexity but in this PR I only addressed the typing.

Let's consider that in a separate PR.

[codecov]

Codecov Report

Merging #2376 (0ae661a) into main (6e0a687) will decrease coverage by 0.073%.
The diff coverage is 84.615%.

@@              Coverage Diff              @@
##              main     #2376       +/-   ##
=============================================
- Coverage   87.183%   87.109%   -0.074%     
=============================================
  Files           60        60               
  Lines         5017      5027       +10     
  Branches       904       905        +1     
=============================================
+ Hits          4374      4379        +5     
- Misses         470       475        +5     
  Partials       173       173               

Impacted Files	Coverage Δ
sanic/mixins/listeners.py	96.428% <81.818%> (-3.572%)	⬇️
sanic/models/handler_types.py	100.000% <100.000%> (ø)
sanic/app.py	89.147% <0.000%> (-0.582%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6e0a687...0ae661a. Read the comment docs.

[ahopkins]

Alternative solutions

I've also considered another way to go around this by separating listener into two methods which should reduce complexity but in this PR I only addressed the typing.

No rush on this, but do you think you can put this alternative version together as a PR for the June release?

[aericson]

Alternative solutions

I've also considered another way to go around this by separating listener into two methods which should reduce complexity but in this PR I only addressed the typing.

No rush on this, but do you think you can put this alternative version together as a PR for the June release?

Yep, I can put some time into that. Are you thinking on us closing this PR and having a new one with that? Just wondering if I should do on top of this changes or from a clean branch.

[ahopkins]

Yep, I can put some time into that. Are you thinking on us closing this PR and having a new one with that? Just wondering if I should do on top of this changes or from a clean branch.

As a new PR separate from this. I am getting the tests to pass and will merge this one in today for the release next week. The other change I think is good, but let's hold off until next cycle (unless you get it done in the next day or so, then we can include it also).