Repository navigation
Replace uses of type variable "value restriction" with "constraints" #17828
Description
Documentation
@JelleZijlstra noticed that our terminology is inconsistent with how we call these at runtime (#17816 (comment)).
This refers to code like this:
def f[T: (int, float)](x: T) -> T: ...
Activity
erictraut commentedon Sep 25, 2024
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.
JelleZijlstra commentedon Sep 25, 2024
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
typing.TypeVarattribute, so I think it makes sense to use the same term consistently in static typing contexts.JukkaL commentedon Sep 26, 2024
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.
wyattscarpenter commentedon May 15, 2025
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.
docs: rename "value restriction" to "value-constrained type variable"
docs: rename "value restriction" to "value-constrained type variable" (…