[ty] Default to latest supported python version#17938
Merged
MichaReiser merged 2 commits intomainfrom May 8, 2025
Merged
Conversation
MichaReiser
requested review from
AlexWaygood,
carljm,
dcreager and
sharkdp
as code owners
MichaReiser
commented
May 8, 2025
Comment on lines
+62
to
+65
| pub const fn latest_ty() -> Self { | ||
| Self::PY313 | ||
| } | ||
|
|
Member
Author
There was a problem hiding this comment.
I added this as a precaution that we don't accidentally bump the Python version in ty when bumping the version for ruff
Contributor
|
Contributor
|
AlexWaygood
approved these changes
May 8, 2025
Member
|
uh, looks like you have some snapshot issues on Windows |
Member
not sure I totally understand what you're saying here, but we can defer this discussion to a later date 😆 |
Member
Author
|
I'm confused. I expected some push back from you @AlexWaygood ;) I should probably have called out the trade offs in the summary. So let me do it here. Defaulting to the latest supported Python version comes with its trade-offs.
I'm leaning towards defaulting to the newest Python version because we already have experience with what it means to default to the oldest version from Ruff and i want to use the alpha to get some feedback for doing the opposite. I also think that part of the solution will be to get better at detecting the fallback version (by e.g. using uv)
Whoops, |
Member
|
Oh, I'm well aware of the tradeoffs. This is going to lead to false negatives, and maybe some false positives too. But the current situation is confusing for users, and I'm tired of arguing about whether this is the best solution or not. I'm more interested in moving on and exploring ways to avoid falling back to this default at all:
|
Member
|
TL;DR this solution has problems that I'm still unhappy with, but on net I think probably reduces very real confusion for users, and I think there are very obvious ways in which we can mitigate the problems in followups. |
carljm
approved these changes
May 8, 2025
Contributor
carljm
left a comment
carljm
left a comment
There was a problem hiding this comment.
Looks good, thank you!
I don't think any option is great when we are just arbitrarily choosing a default with no information, but it seems pretty clear to me that this option is the best available, and the way to improve it is to need the fallback default less often.
dcreager
added a commit
that referenced
this pull request
May 8, 2025
* main: [ty] Respect the gradual guarantee when reporting errors in resolving MROs (#17962) Convert `Message::SyntaxError` to use `Diagnostic` internally (#17784) [ty] Support extending `__all__` with a literal tuple or set as well as a literal list (#17948) [ty] Make `unused-ignore-comment` disabled by default for now (#17955) [ty] Change default severity for `unbound-reference` to `error` (#17936) [ty] Ignore `possibly-unresolved-reference` by default (#17934) [ty] Default to latest supported python version (#17938) [ty] Generate and add rules table (#17953) Update the schemastore script to match changes in ty (#17952) [ty] Implement `global` handling and `load-before-global-declaration` syntax error (#17637)
dcreager
added a commit
that referenced
this pull request
May 8, 2025
* dcreager/default-typevars: clean up the diff remove trait track in type again clippy Better expansion of default typevars specialize_partial enum for TypeMapping [ty] Respect the gradual guarantee when reporting errors in resolving MROs (#17962) Specialize trait Convert `Message::SyntaxError` to use `Diagnostic` internally (#17784) [ty] Support extending `__all__` with a literal tuple or set as well as a literal list (#17948) [ty] Make `unused-ignore-comment` disabled by default for now (#17955) [ty] Change default severity for `unbound-reference` to `error` (#17936) [ty] Ignore `possibly-unresolved-reference` by default (#17934) [ty] Default to latest supported python version (#17938) [ty] Generate and add rules table (#17953) Update the schemastore script to match changes in ty (#17952) [ty] Implement `global` handling and `load-before-global-declaration` syntax error (#17637)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Default to the latest python version if a project has no
requires-pythonconstraint orenvironment.python-version.I first assumed that this would be more complicated because we would also need to respect the requires-python uppper bound.
However, this isn't necessary because the fallback behavior only applies if a project has no requires-python constraint
(because we error if a requires-python constraint has no lower bound).
I do think that we'll want to have two python versions once we start adding version-dependent lint rules
because we don't want that users see different diagnostics (because they could now make use of some newer syntax)
when running
ty check --python-version <newer>when thererequires-pythonclearly states that they have to support<older-version>.The way this would be implemented is that
tyknows both aminimal-supported-python-versionand apython-versionoption.Closes astral-sh/ty#112
Test Plan
Added CLI test
I verified that none of the projects with mypy primer changes specifies a
requires-pythonconstraint.