Add type hints to webpushpushkin.py

[H-Shay]

Hopefully this is a little easier to parse. Just one file. There are a few mypy errors but I believe they will be resolved once the type hints for notifications.py are accepted and merged.

[DMRobertson]

Mypy appears to be unhappy:

 sygnal/webpushpushkin.py:150: error: List item 0 has incompatible type "Optional[Any]"; expected "str"  [list-item]
sygnal/webpushpushkin.py:180: error: List item 0 has incompatible type "Optional[Any]"; expected "str"  [list-item]
sygnal/webpushpushkin.py:229: error: Argument 3 to "_handle_response" of "WebpushPushkin" has incompatible type "Optional[Any]"; expected "str"  [arg-type]
sygnal/webpushpushkin.py:232: error: List item 0 has incompatible type "Optional[Any]"; expected "str"  [list-item]
sygnal/webpushpushkin.py:250: error: Item "None" of "Optional[Any]" has no attribute "get"  [union-attr]

I think most of these would be fixed by marking Device.pushkin: str.
The last one seems to want an annotation for Device.data.

(Perhaps you have these locally in another commit?)

[DMRobertson]

Nit: it would be nicer to import py_vapid.CaseSensitiveDict on line 26 of the RHS here, along with the other imports from that module.

[H-Shay]

Mypy appears to be unhappy:

So I mentioned this at the top of the PR that I think these errors will be resolved once the changes to notifications.py are merged-is the best thing to do to wait until that happens? Just wasn't sure how to manage the dependencies amongst mypy'd files in separate PR's.

[DMRobertson]

Mypy appears to be unhappy:

So I mentioned this at the top of the PR that I think these errors will be resolved once the changes to notifications.py are merged-is the best thing to do to wait until that happens? Just wasn't sure how to manage the dependencies amongst mypy'd files in separate PR's.

Arg, sorry. You did indeed; I just dived straight into the diff. I think the changes you refer to are in #264 ?

FWIW, I've found this workflow to be okayish for managing this kind of dependency:

I've handled this in the past by starting a second branch based on the first change's branch. Then I target the PR at main/develop/master and mark it as a draft. That means that the PR includes both commits from the first and second branch, so I note in the description "depends on #<number>, first interesting commit is <hash>".

I typically end up

• adding to the first until review passes
• merging the first into main
• rebase the second onto main
• go through review for the second

[DMRobertson]

LGTM. Maybe @squahtx wants to have their say too? Otherwise, I think this is good to go once #264 is merged.

[squahtx]

LGTM. Maybe @squahtx wants to have their say too? Otherwise, I think this is good to go once #264 is merged.

It all looks good to me!

(I wonder if it's tractable to change Dict[str, Any] to Dict[str, object] so that mypy makes us add validation. But that's something for another time.)

[DMRobertson]

Looking good!