Skip to content

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

Open
JukkaL opened this issue Sep 25, 2024 · 4 comments
Open

Replace uses of type variable "value restriction" with "constraints" #17828

JukkaL opened this issue Sep 25, 2024 · 4 comments

Comments

@JukkaL
Copy link
Collaborator

JukkaL commented Sep 25, 2024

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: ...
@erictraut
Copy link

erictraut commented 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
Copy link
Member

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.TypeVar attribute, so I think it makes sense to use the same term consistently in static typing contexts.

@JukkaL
Copy link
Collaborator Author

JukkaL commented 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
Copy link
Contributor

wyattscarpenter commented 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants