Skip to content

[ty] Add a note to the diagnostic if a new builtin is used on an old Python version #18068

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 1 commit into from
May 13, 2025

Conversation

AlexWaygood
Copy link
Member

@AlexWaygood AlexWaygood commented May 13, 2025

Summary

If the user tries to use a new builtin on an old Python version, tell them what Python version the builtin was added on, what our inferred Python version is for their project, and what configuration settings they can tweak to fix the error.

Test Plan

Snapshots and screenshots:

image

@AlexWaygood AlexWaygood added ty Multi-file analysis & type inference diagnostics Related to reporting of diagnostics. labels May 13, 2025
Copy link
Contributor

github-actions bot commented May 13, 2025

mypy_primer results

Changes were detected when running on open source projects
hydra-zen (https://github.com/mit-ll-responsible-ai/hydra-zen)
- error[type-assertion-failure] tests/annotations/declarations.py:956:5: Argument does not have asserted type `PBuilds[@Todo(Support for `typing.TypeAlias`)] | StdBuilds[@Todo(Support for `typing.TypeAlias`)]`
- error[type-assertion-failure] tests/annotations/declarations.py:961:5: Argument does not have asserted type `PBuilds[@Todo(Support for `typing.TypeAlias`)] | StdBuilds[@Todo(Support for `typing.TypeAlias`)]`
- Found 649 diagnostics
+ Found 647 diagnostics

@AlexWaygood AlexWaygood force-pushed the alex/new-builtins-note branch from dcb1a5c to a06f9ed Compare May 13, 2025 13:40
Copy link
Member

@BurntSushi BurntSushi left a comment

Choose a reason for hiding this comment

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

Love it!

@AlexWaygood AlexWaygood force-pushed the alex/new-builtins-note branch from a06f9ed to 2ab9783 Compare May 13, 2025 13:48
Copy link
Member Author

Choose a reason for hiding this comment

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

all the line numbers here changed because I added an import to the top of diagnostic.rs...

Copy link
Member

Choose a reason for hiding this comment

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

how dare you

Copy link
Member

@MichaReiser MichaReiser left a comment

Choose a reason for hiding this comment

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

Nice

Comment on lines +1660 to +1665
// TODO: can we tell the user *why* we're inferring this target version?
// CLI flag? pyproject.toml? Python environment?
diagnostic.info(format_args!(
"The inferred target version of your project is Python {}",
Program::get(context.db()).python_version(context.db())
));
Copy link
Member

Choose a reason for hiding this comment

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

This shouldn't be too hard. We have the information if it comes from the CLI or configuration but we throw it away when converting it to a ProgramSettings.

@AlexWaygood AlexWaygood merged commit c0f2292 into main May 13, 2025
35 checks passed
@AlexWaygood AlexWaygood deleted the alex/new-builtins-note branch May 13, 2025 14:08
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.

This is awesome!

// TODO: can we tell the user *why* we're inferring this target version?
// CLI flag? pyproject.toml? Python environment?
diagnostic.info(format_args!(
"The inferred target version of your project is Python {}",
Copy link
Contributor

Choose a reason for hiding this comment

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

It seems a bit odd to call it the "inferred" Python version if it came from eg a CLI flag. But I guess this is part of the TODO above?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes and yes

dcreager added a commit that referenced this pull request May 13, 2025
…eep-dish

* origin/main:
  [ty] __file__ is always a string inside a Python module (#18071)
  [ty] Recognize submodules in self-referential imports (#18005)
  [ty] Add a note to the diagnostic if a new builtin is used on an old Python version (#18068)
  [ty] Add tests for `else` branches of `hasattr()` narrowing (#18067)
  [ty] Improve diagnostics for `assert_type` and `assert_never` (#18050)
  [ty] contribution guide (#18061)
  [ty] Implement `DataClassInstance` protocol for dataclasses. (#18018)
  [ruff_python_ast] Fix redundant visitation of test expressions in elif clause statements (#18064)
Glyphack pushed a commit to Glyphack/ruff that referenced this pull request May 21, 2025
…Python version (astral-sh#18068)

## Summary

If the user tries to use a new builtin on an old Python version, tell
them what Python version the builtin was added on, what our inferred
Python version is for their project, and what configuration settings
they can tweak to fix the error.

## Test Plan

Snapshots and screenshots:


![image](https://github.com/user-attachments/assets/767d570e-7af1-4e1f-98cf-50e4311db511)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
diagnostics Related to reporting of diagnostics. ty Multi-file analysis & type inference
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants