-
Notifications
You must be signed in to change notification settings - Fork 1k
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] Move, rename and make public the PyVersion
type
#12782
Conversation
…:PyVersion`, and make it public
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Merge conflicts ahead 😆
|
||
/// Enumeration of all supported Python versions | ||
/// | ||
/// TODO: unify with the `PythonVersion` enum in the linter/formatter crates? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be TargetVersion
?
/// TODO: unify with the `PythonVersion` enum in the linter/formatter crates? | |
/// TODO: unify with the `TargetVersion` enum in the linter/formatter crates? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The equivalent enum in the linter/formatter crates is called PythonVersion
, e.g.
pub enum PythonVersion { |
/// Unlike [`TargetVersion`], this does not necessarily represent | ||
/// a Python version that we actually support. | ||
#[derive(Debug, Clone, Copy, Eq, PartialEq, Ord, PartialOrd, Hash)] | ||
pub struct PythonVersion { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't need to make this change in this PR but I think it's now a bit confusing when to use TargetVersion
vs PythonVersion
? Shouldn't all (or at least most) our code be open for new Python versions? Or to phrase it differently, what's the benefit of limiting TargetVersion
to a fixed set?
To me, the main reason why TargetVersion
is an enum is just that it was easier to reference specific versions. But I think that can also be accomplished by PythonVersion
, we can define constants for the versions that we care about (and we can implement Default
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, maybe. Having it as an enum is also useful for command-line parsing. But you might be right that we could just use the PythonVersion
type everywhere. Not sure; worth experimenting with as a followup, anyway!
red_knot_python_semantic::module_resolver::typeshed::versions::PyVersion
, and make it publicPyVersion
type
Summary
Working on #12759 has revealed that we need a general-purpose type that represents an arbitrary Python version (not necessarily one that we support), as well as a closed enumeration of supported Python versions. We actually already have a type like that -- but it's currently buried in
red_knot_python_semantic::module_resolver::typeshed::versions
. This PR publicly exposes that type, and moves both that type and theTargetVersion
enum into a newred_knot_python_semantic::python_version
submodule. This will allow the type to be used in #12759, and possibly elsewhere in the future as well.Test Plan
cargo test -p red_knot_python_semantic