I think the OAuth classes in each integration could define the register and create_client methods (the Flask client appears to already do this for some unique logic specific to Flask) while mostly just calling the super class methods but also define the return type specific to them in a type annotation. For example the Django integration could look something like...
This would allow the class inheritance structure to remain the same while giving the benefits of the IDE knowing what type is being returned. There is a slight issue with trying to figure out if you are dealing with an OAuth1 or OAuth2 version of the class. But the interfaces for those seem to remain consistent at the method level so maybe that wouldn't be as much of an issue.
Describe alternatives you've considered
I've tried overriding the return types in comments in my code but (at least for pylance) it still complains as it can't confirm the methods will always return a DjangoOAuth2App instance.
Additional context
I would be happy to try to open a PR for this if the solution proposed above seems tenable. Thanks!
Is your feature request related to a problem? Please describe.
When clients are registered. Pylance is unable to resolve the type of client class that is retrieved from the registry.
A proposed solution from https://github.com/lepture/authlib/issues/410 was to use the
create_client
method instead but this also does not seem to work. The following code...Still produces this error...
Describe the solution you'd like
I think the OAuth classes in each integration could define the
register
andcreate_client
methods (the Flask client appears to already do this for some unique logic specific to Flask) while mostly just calling the super class methods but also define the return type specific to them in a type annotation. For example the Django integration could look something like...This would allow the class inheritance structure to remain the same while giving the benefits of the IDE knowing what type is being returned. There is a slight issue with trying to figure out if you are dealing with an OAuth1 or OAuth2 version of the class. But the interfaces for those seem to remain consistent at the method level so maybe that wouldn't be as much of an issue.
Describe alternatives you've considered
I've tried overriding the return types in comments in my code but (at least for pylance) it still complains as it can't confirm the methods will always return a
DjangoOAuth2App
instance.Additional context
I would be happy to try to open a PR for this if the solution proposed above seems tenable. Thanks!