Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Typing to args and class attributes #16

Open
thehesiod opened this issue Jan 12, 2020 · 11 comments
Open

Add Typing to args and class attributes #16

thehesiod opened this issue Jan 12, 2020 · 11 comments
Labels

Comments

@thehesiod
Copy link

No description provided.

@jupiterbjy
Copy link
Contributor

CLIENT_CREDS = {
"client_id": config["client_creds"]["client_id"],
"client_secret": config["client_creds"]["client_secret"],
"scopes": config["client_creds"]["scopes"],
"redirect_uri": "http://localhost:5000/callback/aiogoogle",
}
state = create_secret() # Shouldn't be a global hardcoded variable.
LOCAL_ADDRESS = "localhost"
LOCAL_PORT = "5000"
app = Sanic(__name__)
aiogoogle = Aiogoogle(client_creds=CLIENT_CREDS)

I can see Aiogoogle.client_creds was meant to accept the dict.

However, in docstring:

api_key (aiogoogle.auth.creds.ApiKey): Google API key
user_creds (aiogoogle.auth.creds.UserCreds): OAuth2 cser credentials
client_creds (aiogoogle.auth.creds.ClientCreds): OAuth2 client credentials
service_account_creds (aiogoogle.auth.creds.ServiceAccountCreds): Service account credentials

Which then makes linter to give false warning like below:

image

Previously I thought adding Union[] on docstring would be enough, turns out PEP-484 actually does not mention anything about use of typing.Union inside docsting, and therefore not properly supported by IDEs.

So only viable option would be making proper annotations, I'll try to make PL if I manage to annotate it later on.

@omarryhan
Copy link
Owner

Hmmm, interesting. The reason I added the ClientCreds model in the docstring in the first place was to have it documented in the docs. The ClientCreds model inherits from dict. Probably not best practice. But I'm open to changing it as long as everything is backwards compatible. Thanks!

@omarryhan
Copy link
Owner

omarryhan commented Jan 19, 2022 via email

@jupiterbjy
Copy link
Contributor

jupiterbjy commented Jan 19, 2022

Well... Seems like best bet is to add Type Annotation and keeping type hint in docstring at same time, as definition part get dirty really quickly.

image

Above result is from code change of following:

class Aiogoogle:
    # ...
    """
    Arguments:

        session_factory (aiogoogle.sessions.abc.AbstractSession): AbstractSession Implementation. Defaults to ``aiogoogle.sessions.aiohttp_session.AiohttpSession``

        api_key (aiogoogle.auth.creds.ApiKey | str): Google API key

        user_creds (aiogoogle.auth.creds.UserCreds | Mapping): OAuth2 cser credentials

        client_creds (aiogoogle.auth.creds.ClientCreds | Mapping): OAuth2 client credentials

        service_account_creds (aiogoogle.auth.creds.ServiceAccountCreds | Mapping): Service account credentials
    """

    def __init__(
        self,
        session_factory: Type[AbstractSession] = AiohttpSession,
        api_key: Union[ApiKey, str] = None,
        user_creds: Union[UserCreds, Mapping] = None,
        client_creds: Union[ClientCreds, Mapping] = None,
        service_account_creds: Union[ServiceAccountCreds, Mapping] = None,
    ):

And this do fix false warning when passing dict.
image


I'm not sure if cleaner alternative is possible, considering other projects that's using readthedocs.org are also having very complex-looking argument page - They decided to keep both type hints on type annotation and docstring.

image

So yeah, I'll say it's totally possible to make it backward-compatible but also I'm no expert!

I'm leaving final decision up to you!

@jupiterbjy
Copy link
Contributor

jupiterbjy commented Jan 19, 2022

Yeah feel free to make this change. As long as getitem/setitem methods work
and values can be accessed using this syntax user_dict['item_name'].

Actually I thought about it again and reached conclusion "Why fix when there's no issue?" - So I removed that comment.

I think the UserDict object didn't exist in Python when I first wrote this
lib. Not sure though. If UserDict isn't supported in py3.6, then I'm not
sure this change is worth it? 🤔

As far as I know it was added on Python 3.7, depending on when you created this repository it might not existed!

@omarryhan
Copy link
Owner

The changes you made to the Aiogoogle class look very good to me. I think it's worth it to litter the blue part of the docs if it gives us better typing in IDEs. Most people will be looking at the parameters section anyways.

@omarryhan
Copy link
Owner

As far as I know it was added on Python 3.7, depending on when you created this repository it might not existed!

Let's stick with supporting Py3.6 then.

"Why fix when there's no issue?"

Agreed

@jupiterbjy
Copy link
Contributor

Ah wasn't it targeting 3.7? Somehow aiogoogle on pypi is reporting 3.7

@omarryhan
Copy link
Owner

Pypi is missing some targets it seems. In the test suite (Tox) and Github Actions we're testing for 3.6.

e.g. here https://github.com/omarryhan/aiogoogle/blob/master/.github/workflows/action.yml#L56 and here: https://github.com/omarryhan/aiogoogle/blob/master/tox.ini#L2

@jupiterbjy
Copy link
Contributor

I checked and it was I who was being dumb; changes I mentioned are totally unnecessary, it was me who was feeding wrong dict structure (Feeding string to scope, not list) to Aiogoogle, sorry!

@omarryhan
Copy link
Owner

omarryhan commented Jan 21, 2022 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants