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] Document public symbol type inference #15766

Merged
merged 1 commit into from
Jan 27, 2025
Merged

Conversation

sharkdp
Copy link
Contributor

@sharkdp sharkdp commented Jan 27, 2025

Summary

Adds a slightly more comprehensive documentation of our behavior regarding type inference for public uses of symbols. In particular:

  • What public type do we infer for x: int = any()?
  • What public type do we infer for x: Unknown = 1?

Adds a slightly more comprehensive documentation of our behavior
regarding type inference for public uses of symbols. In particular:

- What public type do we infer for `x: int = any()`?
- What public type do we infer for `x: Unknown = 1`?
@sharkdp sharkdp added testing Related to testing Ruff itself red-knot Multi-file analysis & type inference labels Jan 27, 2025
Comment on lines +221 to +222
reveal_type(a) # revealed: Unknown | Literal[1]
reveal_type(b) # revealed: Unknown
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This behavior is the main thing I wanted to document.

@sharkdp sharkdp merged commit 2ef94e5 into main Jan 27, 2025
21 checks passed
@sharkdp sharkdp deleted the david/public-type-tests branch January 27, 2025 09:52
@AlexWaygood AlexWaygood changed the title [red-knot] Document public symbol type inferece [red-knot] Document public symbol type inference Jan 27, 2025
a = 1

# Declared with `Unknown`:
b: Unknown = 1
Copy link
Contributor

Choose a reason for hiding this comment

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

I think something that is noteworthy here is that the entire purpose of Unknown (as distinct from Any) is to distinguish a dynamic type that originates from an explicit annotation vs one that originates from lack of annotation. So the whole idea of "declared with Unknown" is a contradiction. We have made it possible by introducing knot_extensions.Unknown, but perhaps that is just confusing and was a mistake? It should really only be used in tests, but I would guess that in most cases we could structure the test so as to generate an Unknown type via lack-of-annotation instead (e.g. an un-annotated function parameter).

Copy link
Contributor

Choose a reason for hiding this comment

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

Actually I just realized that "declared with Unknown" is not a contradiction; it could occur anytime someone annotates with a name we can't resolve, or an invalid type expression.

Still not totally clear to me whether tests for this case are better written using knot_extensions.Unknown (which is clear and explicit, but not "realistic") or using an actual unknown name (which then requires suppressing the unknown-name diagnostic.) I can see good arguments both ways, so no strong feelings.

dcreager added a commit that referenced this pull request Jan 27, 2025
* main:
  Run `cargo update` (#15769)
  [red-knot] Document public symbol type inferece (#15766)
  Update dawidd6/action-download-artifact action to v8 (#15760)
  Update NPM Development dependencies (#15758)
  Update pre-commit dependencies (#15756)
  Update dependency ruff to v0.9.3 (#15755)
  Update dependency mdformat-mkdocs to v4.1.2 (#15754)
  Update Rust crate uuid to v1.12.1 (#15753)
  Update Rust crate unicode-ident to v1.0.15 (#15752)
  Fix docstring in ruff_annotate_snippets (#15748)
  Update Rust crate insta to v1.42.1 (#15751)
  Update Rust crate clap to v4.5.27 (#15750)
  Add references to `trio.run_process` and `anyio.run_process` (#15761)
  [`ruff`] Do not emit diagnostic when all arguments to `zip()` are variadic (`RUF058`) (#15744)
  [red-knot] Ensure differently ordered unions are considered equivalent when they appear inside tuples inside top-level intersections (#15743)
  [red-knot] Ensure differently ordered unions and intersections are understood as equivalent even inside arbitrarily nested tuples (#15740)
  [red-knot] Promote the `all_type_pairs_are_assignable_to_their_union` property test to stable (#15739)
  [`pylint`] Do not trigger `PLR6201` on empty collections (#15732)
  Improve the file watching failure error message (#15728)
  Speed symbol state merging back up (#15731)
sharkdp added a commit that referenced this pull request Jan 28, 2025
…15787)

## Summary

Do not use an explict `knot_extensions.Unknown` declaration, as per
[this
comment](#15766 (comment)).
Instead, use an undefined name to achieve the same effect.
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 testing Related to testing Ruff itself
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants