abstract method for "requests" has different signature to implementations.

[papadeltasierra]

Describe the bug
Was attempting to create some good type stubs and got these errors:

Running mypy for Python 3.8...
*** Testing Python 3.8 on linux
Testing third-party packages...
testing dropbox (31 files)... failure (exit code 1)

stubs/dropbox/dropbox/dropbox_client.pyi:70: error: Definition of "request" in base class "_DropboxTransport" is incompatible with definition in base class "DropboxBase"  [misc]
stubs/dropbox/dropbox/dropbox_client.pyi:72: error: Definition of "request" in base class "_DropboxTransport" is incompatible with definition in base class "DropboxTeamBase"  [misc]

Tracked down the to abstract method signatures in DropboxBase and DropTeamBase being different to that in _DropboxTransport.

To Reproduce
Follow steps in CONTRIBUTING.md for thetypeshed repository.

Expected Behavior
No error above.

Actual Behavior
Errors as indicated.

Screenshots
N/A

Versions
v12.0.2
Python
Distributor ID: Ubuntu
Description: Ubuntu 22.04.4 LTS
Release: 22.04
Codename: jammy

Additional context
Solution is probably to make abstract signatures match the implementation in _DropboxTransport.

[greg-db]

Thanks! For reference though, can you share the specific code/command(s) you ran that resulted in these errors? That way I can make sure the team has the relevant information to review and reproduce this.

[papadeltasierra]

I'm trying to create some type checking stubs via typeshed in a fork here: https://github.com/papadeltasierra/typeshed. It is there CI checks that alerted me to this. presently I've added some ignore this warning markers to get around this and referenced this issue in the code.

[greg-db]

Thanks for following up. If you'd like to report an issue with the Dropbox Python SDK, please let us know the specific steps we can use to reproduce the issue here. Thanks!

[papadeltasierra]

If you look at your code (dropbox-api-python) for the definitions of the three classes mentioned, you will see there is an abstract method that is then defined as a concrete implementation in the subclasses. But the signatures of the abstract and the concrete methods are different. (Runtime) Python doesn't seem to care too much about this but type-checking does. The generated typing hints in my typeshed implementation are almost entirely autogenerated but (see below stubs/dropbox/dropbox) you will see that I have had to add ignore error suppression to stop the abstract/concrete method signature mismatches from causing the various CI checks to fail.
I believe the signatures should be made to match and cannot see any reason why they should be different.
Does this give you enough information and do you disagree with my final assertion?

[greg-db]

Thanks! I'll send this along to the team.