Skip to content

Document how to test type annotations #1071

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

Merged
merged 2 commits into from
Feb 21, 2022
Merged

Conversation

sirosen
Copy link
Contributor

@sirosen sirosen commented Feb 12, 2022

The goal of this PR is to resolve python/mypy#11506 and document how to test type annotations.
In terms of presentation, the goal is to present guidance and offer up several options, many of which were proposed by contributors to that issue. I have attempted to present all of the information without bias, and everyone in that prior conversation deserves credit for their thoughts and input.

This is a broader refactor than just testing, though testing is the primary content.
It also consolidates information about checking type coverage/completeness.

Several of the goals from that thread were not achieved here, including documentation covering stubgen and monkeytype, stubtest, and potentially more. However, the document is written such that it should be possible to add a section on "Generating Annotations" as was planned earlier.

This is a slightly broader refactor than just testing. It also
consolidates information about checking type coverage/completeness.

This originates from a thread on the mypy tracker [1]. In terms of
presentation, the goal is to present guidance and offer up several
options, many of which were proposed by contributors to that thread.

Several of the goals from that thread were not achieved here,
including documentation covering stubgen and monkeytype, stubtest, and
potentially more. However, the document is written such that it should
be possible to add a section on "Generating Annotations" as was
planned earlier.

[1]: python/mypy#11506
@JelleZijlstra
Copy link
Member

Thanks! What you wrote looks good, but it's highly mypy-specific, so it may be a better fit for the mypy docs.

@sirosen
Copy link
Contributor Author

sirosen commented Feb 12, 2022

I agree. The original issue proposed an addition to the mypy docs, but I was asked (by a pyright maintainer, FWIW) to put it here instead.

I don't really care where the doc goes. I just know that when I realized my published types were incorrect, there was no guidance I could find on testing my fixes.

@JelleZijlstra
Copy link
Member

Eric did say "I guess it depends on how mypy-specific it is." :)

You might also be interested in https://mail.python.org/archives/list/typing-sig@python.org/thread/MITFQ6Z45RRMXY3HNM66IC3XXS3TA3JN/

@sirosen
Copy link
Contributor Author

sirosen commented Feb 12, 2022

Eric did say "I guess it depends on how mypy-specific it is." :)

You're right. I may have taken a more forceful meaning from his comment than I should have. 😅

It's mostly mypy-centric because that's what I know best. Does your feeling about where this belongs change if I were to add a 30-second intro to monkeytype?
I'm not qualified to write much about most of the other tools, but I remember using monkeytype a couple of years ago.


Aside: I find the typing.assert_type thread very interesting, thanks for sharing!
I could easily get into the naming debate (and shouldn't! 😹 ). One thing I'll note is that between runtime_checkable protocols and the annotation-driven libraries like pydantic, it's easy to imagine people believing that symbols from typing have runtime significance.

@erictraut
Copy link
Collaborator

@sirosen, thanks for writing this. Although it is mypy-centric, I think it's still good to post on this site. Other contributors can then extend it to include tips based on functionality in other tools.

@srittau
Copy link
Collaborator

srittau commented Feb 21, 2022

I agree with @erictraut. I'd rather see this here and extended in the future than in the mypy docs. Are you okay with that, @JelleZijlstra?

@JelleZijlstra
Copy link
Member

Sure, let's do that.

Copy link
Collaborator

@srittau srittau left a comment

Choose a reason for hiding this comment

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

Thanks, a great document! I especially love the --warn-unused-ignores trick. A few notes below.

- one minor typo fix
- rename the doc to "quality" and re-title
- switch to inline links and remove References
@srittau srittau merged commit 02d79c2 into python:master Feb 21, 2022
@sirosen
Copy link
Contributor Author

sirosen commented Feb 21, 2022

I've applied the review suggestions. I think this is good to go now, but I'm happy to do more rounds of review if there are still issues.

I especially love the --warn-unused-ignores trick

I also was very impressed by it, which is why I put it first in the doc!

Credit to @ikonst for explaining it in the original mypy issue.

If I'd known about or thought of that approach first, I might never have written my elaborate mypy.api usage.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Document how to write test-cases for type annotations using mypy (in subprocess)
5 participants