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

Add --pep561-override option to declare package names that are always considered typed #8512

Closed
wants to merge 1 commit into from

Conversation

ntninja
Copy link

@ntninja ntninja commented Mar 8, 2020

Title says it all: Packages declared using this option will not be ignored as found module but no type hints or library stubs.

This is intended as a last resort if one depends on a library that neither provides type hints and there are no external typing stubs available. In my specific use-case I depend on a library that provides some type hints in the code base, but they are incomplete/spotty and so the library authors prefer to not mark the package as PEP-561 compatible until they are more usable. They are still quite helpful when used from mypy however when one keeps their limitations in mind.

This still lacks docs and tests, but I'd like to hear what people here think about this before going down that road.

@ethanhs
Copy link
Collaborator

ethanhs commented Mar 13, 2020

I depend on a library that provides some type hints in the code base, but they are incomplete/spotty and so the library authors prefer to not mark the package as PEP-561 compatible until they are more usable.

Ideally in this situation, a stub package should be created I would argue. This allows for iteration on types (and opting into them while they are unstable) while keeping the main package stable.

I will think about this more.

@ethanhs
Copy link
Collaborator

ethanhs commented Mar 16, 2020

the library authors prefer to not mark the package as PEP-561 compatible until they are more usable.

I have opened #8545 to discuss this further.

@97littleleaf11
Copy link
Collaborator

Hello! Any progress on this PR?

@ethanhs
Copy link
Collaborator

ethanhs commented Nov 26, 2021

I think this will be superseded by an implementation of #8545

@ethanhs ethanhs closed this Nov 26, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants