Skip to content
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[red-knot] Add failing test for use of type[] as a base class #14913

Merged
merged 1 commit into from
Dec 11, 2024

Conversation

AlexWaygood
Copy link
Member

We support using typing.Type[] as a base class (and we have tests for it), but not yet builtins.type[]. At some point we should fix that, but I don't think it';s worth spending much time on now (and it might be easier once we've implemented generics?). This PR just adds a failing test with a TODO.

@AlexWaygood AlexWaygood added the red-knot Multi-file analysis & type inference label Dec 11, 2024
Copy link
Contributor

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

@InSyncWithFoo
Copy link
Contributor

There are also no inheritance tests for tuple just yet. #14916 should add one for Tuple though.

@AlexWaygood
Copy link
Member Author

There are also no inheritance tests for tuple just yet. #14916 should add one for Tuple though.

If you could add one for tuple at the same time as you add them for Tuple, that would be great. It doesn't need to pass the way we'd "like it to"; it's fine for it to record the "wrong" result and have a big TODO comment next to it for now.

@AlexWaygood AlexWaygood merged commit a543533 into main Dec 11, 2024
21 checks passed
@AlexWaygood AlexWaygood deleted the alex/failing-type-t-test branch December 11, 2024 17:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
red-knot Multi-file analysis & type inference
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants