Multiple type errors from mypy

[orsinium]

The async/sync dichotomy of the library makes mypy go crazy. Usually, the first definition of a symbol wins. For example, in auth/session.py:

Incompatible types in assignment (expression has type "ClientSession", variable has type "Optional[Session]")

This is because Session is defined by the first import as from requests import Session (and the second definition as from aiohttp import ClientSession as Session is ignored).

The worst thing is that these errors propagated to the user side too. for example, Storage accepts session argument which is the same Session type as in the previous example. That means, when I try to pass aiohttp.ClientSession into Storage, I get a mypy error.

I can try fixing it by separating async and sync implementations a bit more and throwing a few Union 's in annotations if you're interested.

[TheKevJames]

Yeah, the metaprogramming stuff we've done to support the async/sync split definitely doesn't play nicely with mypy's assumptions. I'd be happy to accept any PRs to improve this sort of thing! The only area I'd want to call out is that our main goal is to avoid needing to "build the same thing twice" across versions; so long as any refactors you suggest keep in this theme, I'm happy :)

Other than that, please be aware that it's easier for us to review and merge smaller PRs -- a single refactor PR which replaces "everything" will take us much longer to work through.

[FedirAlifirenko]

Found the same behavior when passing aiohttp.ClientSession as a session instance into gcloud.aio.auth.token.Token.
gcloud-aio-auth==4.0.1