Add typing to _ConnectionParameters and related functions - #1199
Add typing to _ConnectionParameters and related functions#1199DanielNoord wants to merge 8 commits into
Conversation
Sorry, something went wrong.
|
Based on review in #1198 I have swapped out the stringified annotations for non-stringified behind a from __future__ import annotations. I also had to rebase and force push due to merge conflicts. |
Sorry, something went wrong.
|
|
||
| def _validate_port_spec(hosts, port): | ||
| def _validate_port_spec( | ||
| hosts: Sequence[object], port: typing.Union[int, typing.List[int]] |
There was a problem hiding this comment.
| hosts: Sequence[object], port: typing.Union[int, typing.List[int]] | |
| hosts: typing.List[str], port: typing.Union[int, typing.List[int]] |
Sorry, something went wrong.
There was a problem hiding this comment.
I did this because of line 172. If your suggestion is correct we can remove the else branch. Since I didn't want to change the functionality of the code too much I just added what the code is able to handle instead of what it likely should be, if that makes sense.
Would you want me to change this? Or is keeping as is fine? If it is the latter, could you press the Merge button? :)
Sorry, something went wrong.
|
Would be lovely to get this merged :) |
Sorry, something went wrong.
This adds typing to an important NamedTuple in this module that will allow using types in a lot of other functions that have a reference to this object.
The final type looks very similar to what was suggested in #577 but this is based on the paths that the code can actually take. As with other PRs the strategy is simple: start with the lowest function in the call chain to see if the code can tell you what types it should accept and propagate upwards until you reach the NamedTuple.
The most controversial change is probably _ConnectionParameters.ssl. This is because of the code path where we set sslmode = SSLMode.disable. It is a bit annoying but that code path means that ssl never gets reassigned and therefore will be whatever _parse_connect_dsn_and_args accepts. We should probably change that to be None but I don't want to introduce behaviour changes in these PRs.
The two actual runtime changes are straightforward and any mistakes in the typing we can (of course) always rectify later.