Both mypy and typing.readthedocs.io call the value passed to TypeVar’s bound= kw-only argument an upper bound. The docs for the typing module don’t mention the phrase “upper bound”.
Again, both mypy and typing readthedocs only use the phrase “bound type variable” when “bound” is the past participle of “to bind”, but the docs for the typing module use the phrase “bound type variable” twice to mean “a type variable created with the bound= keyword argument”, which I find quite confusing.
Is the use of “bound type var” in the stdlib docs a mistake? As far as I understand, TypeVars created with a bound should be called “bounded type variables”. (In math, a variable with an upper bound is called a bounded variable.) However, I don’t see the term “bounded type var” being used anywhere (mypy’s docs, typing’s readthedocs, or typing stdlib).
To place a concrete question: Is the use of “bound type variable” in the docs for the stdlib typing module to mean “a TypeVar created using the bound keyword arg” correct? If it’s not, can we change it to “bounded type variable”? If we can’t, what should be used instead?
I would be in favour of changing the mention in stdlib to be “Type variables with upper bound”, matching the wording in mypy docs and the spec.
Drawing a distinction between a “bound type var” and a “bounded type var” feels a little too subtle to me. So my strategy would be to use the long “with upper bound” and hope that PEP 695 means we all end up talking about bound or unbound type variables less often.
For me, a “bound type var” is a type variable that was bound to something (whatever that means) while a “bounded type var” means that it’s a type variable with an upper bound.
I think the current formulation is gramatically incorrect in this context (we are not binding anything, we are adding a boundary to something). In addition, in terms of compiler terminology, “binding” has a special meaning which does not fit in this case (at least not for me). So a “bound TypeVar” would mean that we assigned a specific type to that type variable.
I personally think it’s fine to write “Bounded Type Variables” rather than “Type variables with upper bound” since it’s less verbose but I don’t mind either formulation and can accept the latter since it has no ambiguity.
I understand that using both “bounded” and “bound” could be confusing. Though, like @picnix_, I personally have no problem with it, I also have no problem with the more verbose “with upper bound”.
About these two incorrect instances of “bound type var” in the stdlib docs, should I open a PR? Do I need to create an issue first?
As for the problem of avoiding this issue resurfacing in the future, maybe adding a note at the end of the docs section for TypeVar with a text something like this:
Note: When talking about a type variable with upper bound, avoid the phrase “bound type variable”, since that could be mistaken for a type variable which has been assigned a concrete type value inside a generic function or class.
OK, I just realised that we can’t just replace all incorrect instances of “bound” by “with upper bound” in the stdlib docs, because the stdlib docs never introduced the expression “upper bound” in the first place. (I also realised that there are other instances in typing.rst of “bound” being used to mean “with uppper bound”, not just the two instances I mentioned that appear when I textually search for “bound type var”.)
I will open a PR with a first suggestion of how to do this. Please tell me if I need a github issue first, or if just referencing this discussion is enough.