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

Support type[a.X] with qualified class names #14825

Merged
merged 2 commits into from
Dec 6, 2024
Merged

Conversation

dcreager
Copy link
Member

@dcreager dcreager commented Dec 6, 2024

This adds support for type[a.X], where the type special form is applied to a qualified name that resolves to a class literal. This works for both nested classes and classes imported from another module.

Closes #14545

Comment on lines +74 to +79
# TODO: no diagnostic
# error: [unresolved-attribute]
def f() -> type[a.b.C]:
# TODO: no diagnostic
# error: [unresolved-attribute]
return a.b.C
Copy link
Member Author

@dcreager dcreager Dec 6, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left this as a TODO because I think this is not specific to type[]. The unresolved-attribute error I get is:

Type <module 'System("/src/a/b.py")'> has no attribute b

which suggests that our import logic is binding a as a.b instead of a. Am I interpreting that right?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it looks like you are! I think this is a previously-not-known bug, unless @AlexWaygood was already aware of it. Want to file an issue (labeled red-knot)? Could also be an interesting one for you to look into, would get you some exposure to the module resolver, which I don't think any of the other tasks do.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I already knew about it, and I think we already have a TODO about it... whether we have an issue is another question... it's late here, so I won't look into whether we do or don't this evening :-)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Opened #14826, can close it as a dup if it turns out we have another one already open

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

github-actions bot commented Dec 6, 2024

ruff-ecosystem results

Linter (stable)

✅ ecosystem check detected no linter changes.

Linter (preview)

✅ ecosystem check detected no linter changes.

Copy link
Contributor

@carljm carljm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! Looks like this one would have been a better pick for first task 😆

Comment on lines +74 to +79
# TODO: no diagnostic
# error: [unresolved-attribute]
def f() -> type[a.b.C]:
# TODO: no diagnostic
# error: [unresolved-attribute]
return a.b.C
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it looks like you are! I think this is a previously-not-known bug, unless @AlexWaygood was already aware of it. Want to file an issue (labeled red-knot)? Could also be an interesting one for you to look into, would get you some exposure to the module resolver, which I don't think any of the other tasks do.

let name_ty = self.infer_expression(slice);
if let Some(ClassLiteralType { class }) = name_ty.into_class_literal() {
Type::subclass_of(class)
} else {
todo_type!()
todo_type!("unsupported type[X] special form")
}
}
// TODO: attributes, unions, subscripts, etc.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we can remove "attributes" from this TODO

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@dcreager dcreager merged commit 8fdd880 into main Dec 6, 2024
21 checks passed
@dcreager dcreager deleted the dcreager/qualified-type-of branch December 6, 2024 22:14
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.

[red-knot] understand type[a.X] in a type expression
4 participants