Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Add stubs for async#678

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Closed

Conversation

@David-Gilman
Copy link

@David-GilmanDavid-Gilman commentedFeb 28, 2025
edited
Loading

Changes

Currently type checkers such as pyre, mypy, and those included in IDEs can't handle async functions. This adds partial support by adding.pyi files for the management API functions ending in_async.

References

Resolves:#615

Testing

Tested with IDE and type checkers.

Checklist

kpark-hrp and kishore7snehil reacted with thumbs up emoji
@David-GilmanDavid-Gilman requested a review froma team as acode ownerFebruary 28, 2025 17:21
@David-Gilman
Copy link
Author

@kishore7snehil Could I get a review and a merge please?

@kishore7snehil
Copy link
Contributor

Hey@David-Gilman, I'm reviewing your PR now and will be adding comments soon. However, the merge won't be possible sinceSnyk is failing here. I'll take your changes and create a new PR to address this. I'll make sure to give you proper credits both in the PR and in the release. Thanks for your contribution!

@kishore7snehil
Copy link
Contributor

kishore7snehil commentedMar 19, 2025
edited
Loading

Hey@David-Gilman, I’ve reviewed your PR. Instead of creating multiple.pyifiles for async stubs manually, I’d recommend using a script to handle this, as having too many .pyi files might be confusing for developers.

I already have a script ready for this, and I can share the feature branch with you. You can check out the script in the scripts folder here and try running it using:

poetry run python scripts/generate_stubs.py

This will generate all the required.pyifiles for theauth0/management folder.

Let me know if this approach works for you—if it does, we can close this PR and proceed with the scripted solution.

Also, I’m not in favor of adding.pyi files directly in the repo as it looks odd and can be confusing. Otherwise, we would have just added duplicate functions for async directly in each.py file.

cc:@kpark-hrp

Copy link
Contributor

@kishore7snehilkishore7snehil left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I already have a script ready for this. You can check out the script in the scripts folder here and try running it using:

poetry run python scripts/generate_stubs.py

This will generate all the required.pyifiles for theauth0/management folder.

I’m not in favor of adding.pyi files directly in the repo as it looks odd and can be confusing. Otherwise, we would have just added duplicate functions for async directly in each.py file.

@David-Gilman
Copy link
Author

David-Gilman commentedMar 19, 2025
edited
Loading

@kishore7snehil

That requires anyone use type checkers to maintain their own fork with the .pyi files.

Adding .pyi files is a common practice and would be relatively low maintenance, as well as a good middle ground between no type hints and having to maintain entire duplicate functions.

You could add your script to the CI check so that any changes get updated automatically in the PR.

If you feel strongly about this though and no other maintainers disagree with you, I can open a typeshed PR instead.

@David-Gilman
Copy link
Author

@kishore7snehil Thoughts?

@kishore7snehil
Copy link
Contributor

@David-Gilman I would suggest to go withtypeshed PR.Meanwhile I will look out for adding the script in CI. But I can't give any immediate timeline right now as the team is working on high priority tasks.

@Avasam
Copy link

Avasam commentedApr 12, 2025
edited
Loading

As the stubs are written here. You'd be loosing visibility on all the non-async methods and attributes. And declare the non-async versions of the classes as having_async methods.

Python's static typing system isn't powerful enough to generate attribute out of other attributes, or to extract type from signatures (unlike TypeSrcipt). You can't use base classes as generics either, that would make it so much easier.

Here's one way you could solve this (without changing anything at runtime):
Generate stubs for all classes you expect to "Asyncify" as was talked here. But with the following differences:

  • Generate it in a subfolder that doesn't exist at runtime (ie:auth0._asyncified.*)
  • Rename all the generated classes to help differentiate them (something likeclass UsersWrapped(Users): for base classUsers)
  • Decorate all generated classes with@typing.type_check_only
  • Generate a massive overload forauth0.asyncify.asyncify that maps original classes to stub-only asyncified/wrapped classes.
  • Optional: Generate said stubs on install/editable install/wheel creation. That way they don't pollute the source and history.

2nd option: writing a mypy plugin. But obviously that only works for mypy, and not other checkers.

@Avasam
Copy link

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@kishore7snehilkishore7snehilkishore7snehil left review comments

+1 more reviewer

@kpark-hrpkpark-hrpkpark-hrp approved these changes

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Add stubs for _async methods

4 participants

@David-Gilman@kishore7snehil@Avasam@kpark-hrp

[8]ページ先頭

©2009-2025 Movatter.jp