-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
Replace uses of type variable "value restriction" with "constraints" #17828
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
Comments
PEP 484 didn't formally define a term for type variables of this sort. I've seen them commonly referred to as "constrained type variables" and less commonly as "restricted type variables". @JukkaL, I presume that you were the original designer of this concept? What term do you suggest? Is "value-restricted type variable" your preference? It would be good for us to bless an official term and use it consistently throughout the typing spec and in the documentation for mypy, pyright, etc. This would help reduce confusion. In PEP 695, Jelle and I refer to these as "constrained type variables". That was perhaps a bad choice in terminology because all type variables have some constraints (e.g. upper / lower bounds and variance). In the pyright documentation and source code, I tend to use the term value-constrained type variables. I was planning to propose that we officially adopt this term in the typing spec, but I'm open to other terminology if you have a suggestion. |
They are referred to as "constraints" at runtime, and it's been like that since 3.6 (link). Backward compatibility for CPython means we can't change the name of the |
Using a term that aligns with the runtime name seems like the best option, and it would be nice if the typing spec, user documentation and different type checkers could agree on a single term. We can also mention all former names that have been used for the concept in the mypy docs, but we'd primarily stick to the official term. I think "Value-constrained type variables" is a reasonable name that works with the runtime name, and isn't too far away from the terms we've been using so far. |
It seems a bit unfortunate to call them "value-constrained type variables" when you can't constrain them using values; you have to constrain them using types. I suppose the reasoning is that the values are constrained (but isn't that how a type variable always works, come to think of it?) Cross-referencing the previously-mentioned
I think the most natural and prevalent choice of terminology is calling them "constrained type variables" and "bounded type variables", and one just has to accept these as new specialized terms of art in this context. However, in certain contexts (such as introducing the concepts) one could use the more-elaborate "type variables constrained to exact types" and "type variables bounded by a supertype", or even "exact-types-contrained type variables" and "supertype-bounded type variables". In other news, there are only about 10 hits for value restriction in this repo, so those should be easy to mop up. |
Documentation
@JelleZijlstra noticed that our terminology is inconsistent with how we call these at runtime (#17816 (comment)).
This refers to code like this:
The text was updated successfully, but these errors were encountered: