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] PEP 561 compliant module resolver #11653

Open
15 of 18 tasks
carljm opened this issue May 31, 2024 · 4 comments
Open
15 of 18 tasks

[red-knot] PEP 561 compliant module resolver #11653

carljm opened this issue May 31, 2024 · 4 comments
Assignees
Labels
red-knot Multi-file analysis & type inference

Comments

@carljm
Copy link
Contributor

carljm commented May 31, 2024

(Or intentional choices to diverge from PEP 561 compliance.)

Subtasks:

@carljm carljm added the red-knot Multi-file analysis & type inference label May 31, 2024
@carljm carljm changed the title PEP 561 compliant module resolver [red-knot] PEP 561 compliant module resolver May 31, 2024
@MichaReiser
Copy link
Member

One thing that we need to implement as part of this is a vendored filesystem. It's not a functionality but a task to complete on our way to get there.

@AlexWaygood
Copy link
Member

One thing that we need to implement as part of this is a vendored filesystem. It's not a functionality but a task to complete on our way to get there.

Right. I was considering that part of

Use vendored typeshed stubs at runtime to resolve symbols to stdlib definitions if --custom-typeshed-dir is not passed

since, as you say, it's necessary to implement a vendored filesystem in order to be able to do that

@MichaReiser
Copy link
Member

@AlexWaygood is there more work that needs doing or can we consider this done?

@AlexWaygood
Copy link
Member

AlexWaygood commented Oct 30, 2024

We can't call ourself PEP-561-compliant until we do this, which is still outstanding, and important. It's not huge, but also not trivial:

* [ ]  Add support for stubs packages suffixed with `-stubs` installed into `site-packages

But we decided to defer work on it for now because the type-inference work is more important.

We should also add support for py.typed files that explicitly mark type annotations as partial, which is specified by the PEP but not listed in the tasks above; I'll add that now.

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

No branches or pull requests

3 participants