Metaclass issues in stubs for Redis

[github-actions]

Runs listed here: https://github.com/python/typeshed/actions/workflows/daily.yml

[JelleZijlstra]

Metaclass stuff in various third-party packages, I guess from the new mypy release. #9123's CI should ideally have caught it.

[sobolevn]

I am working on fixing metaclasses stuff.
During the process I also can double check that this feature is:

1. Correct
2. Useful

[AlexWaygood]

Two thoughts:

• We may as well just skip stubtest for cryptography at this point. Those stubs are obsolete, pinned to a very old version, and will be deleted as soon as other typeshed stubs can depend on upstream cryptography rather than types-cryptography (Remove cryptography (depends on #5952) #5618)
• There are so many errors for SQLAlchemy and Redis, that maybe we should just allowlist all the metaclass errors for those libraries for now. We can then work through the allowlist at our own pace, without worrying about stubtest failing on a daily basis.

[sobolevn]

Observations:

1. This error does not look good:

 error: invoke.parser.ParseMachine is inconsistent, metaclass differs
Stub: at line 15 in file /home/runner/work/typeshed/typeshed/stubs/invoke/invoke/parser/__init__.pyi
N/A
Runtime: at line 176 in file /tmp/tmpswurkl33/lib/python3.9/site-packages/invoke/parser/parser.py
<class 'invoke.vendor.fluidity.machine.MetaStateMachine'>

error: invoke.parser.parser.ParseMachine is inconsistent, metaclass differs
Stub: at line 15 in file /home/runner/work/typeshed/typeshed/stubs/invoke/invoke/parser/parser.pyi
N/A
Runtime: at line 176 in file /tmp/tmpswurkl33/lib/python3.9/site-packages/invoke/parser/parser.py
<class 'invoke.vendor.fluidity.machine.MetaStateMachine'>

It is the same object, but re-exported in different modules. No need to report it twice.

2. We now have a lot of stuff in allowlists for some modules. I think it might be a good idea to add error codes. Right now all errors might be ignored.

3. Problem with types that do not have abstract methods and still have ABCMeta metaclass. Might be a good idea to special case this.

[AlexWaygood]

It is the same object, but re-exported in different modules. No need to report it twice.

Stubtest does that with any object that's re-exported in another module. (It's not ideal behavior, but it's not unique to the new metaclass-related check.)

[AlexWaygood]

• There are so many errors for SQLAlchemy and Redis, that maybe we should just allowlist all the metaclass errors for those libraries for now. We can then work through the allowlist at our own pace, without worrying about stubtest failing on a daily basis.

To update on the status here: I believe @Avasam fixed all the SQLAlchemy metaclass issues. There may still be quite a few metaclass-related allowlist entries for our Redis stubs that we could fix, however.

[Avasam]

Concerning Redis: Subclassing CommandsProtocol like the source does fix the differing metadata issue, however CommandsProtocol has a member connection_pool that is not implemented by its subclasses.
I've open an issue about this upstream: redis/redis-py#2730 and redis/redis-py#2729
Not sure what would be the best way to tackle this in typeshed.

• We could add >50 # type: ignore[misc] # pyright: ignore [reportGeneralTypeIssues] that may be flagged once fixed upstream.
• Lie in the stub and add the missing member (curiously stubtest doesn't flag this, see Demo potential fix for stubtest metaclass issues with Redis #10115)
• Wait for it to maybe be fixed upstream