__init__ arguments in base class are handled incorrectly.

[vistatest]

Describe the bug
Does not handle correctly __init__() parameters that are defined in a base class for one of inherited mixed-in classes.

To Reproduce

from itsdangerous import URLSafeTimedSerializer
...
    self.tokenManager = URLSafeTimedSerializer(secret_key)

Got pyright error message: Expected no arguments to 'URLSafeTimedSerializer' constructor
But one of the base classes to URLSafeTimedSerializer has eventually a base class where __init__() has parameters.

Expected behavior
Should not see an error.

Screenshots or Code
See above.

VS Code extension or command-line
VSCode pyright 1.0.32

Additional context
https://github.com/pallets/itsdangerous

[erictraut]

Are you using a type stub file for itsdangerous? If so, could you post that here? I don't see a type stub file (e.g. itsdangeours.pyi or init.pyi) in the itsdangerous repo, so perhaps you've created a custom one?

If you're not using a type stub file, pyright will not know anything about the imported symbol — its type will be "Unknown", and it should not generate any errors for its usage. I just confirmed this by using the following code:

from itsdangerous import URLSafeTimedSerializer
secret_key = ''
URLSafeTimedSerializer(secret_key)

[vistatest]

I'm using typeshed, not the one in pypy (that one was never updated since 0.0.1) but cloned recently from https://github.com/python/typeshed. It contains third_party/2and3/itsdangerous.pyi.
typeshedPath in my pyrightconfig.json points to a typeshed repo on a local system.

[erictraut]

Thanks for the bug report. This is indeed a bug, and it will be fixed in the next version.

If you're interested, it occurs only in cases where a class derives from multiple subclasses and there is no __init__ method on the entire class hierarchy of the first base class. In this case, the type checker was assuming it should use the __init__ method for object, which has no parameters.

[erictraut]

This is now fixed in version 1.0.33, which I just published. Thanks again for the bug report.

[vistatest]

Great! Thank you.
I wonder if anything could be done for SQLAlchemy?
There are stubs in https://github.com/dropbox/sqlalchemy-stubs, but no easy way to point pyright to them - giving a list of paths and/or URLs with stubs would be nice. And I'm not sure the stubs are processed correctly.
Should I open a separate bug report?

[erictraut]

Pyright supports a "typingsPath" setting. It's intended to point to a local directory within your code base that includes custom type stubs that you write and maintain for imported libraries that do not provide their own. That's what I use for my team's source base. I created a top-level subdirectory called "typestubs". Beneath that are directories with the names of each imported module, and I've created typestub files in each of those folders. Does that address your needs?