GeezerVison

The name "evaluate_bound" isn't set in stone; it was added during the 3.14 alphas and does not yet have any compatibility constraints. However, I think it should match the bound= argument to the TypeVar constructor and the __bound__ attribute, so I wouldn't support changing the name.

Using "upper bound" instead of "bound" in the documentation seems like a good idea.

Using "upper bound" instead of "bound" in the documentation seems like a good idea.

Agreed!

There. I also changed the two instances of "bound" as noun to "upper bound", as mentioned in the OP.

I still feel that the expressions "bounded" and "upper bound" may appear disconnected. Maybe the similarity of the words is enough to imply that the expressions are talking about the same thing, but maybe it's not clear for a reader not used to typing -- I'm really not sure. (Also, maybe it's just that English is not my native language.)

Currently, the first time both expressions appear is in the following snippet. Perhaps adding just this small note would be enough?

   This syntax can also be used to create bounded and constrained type
   variables::

      class StrSequence[S: str]:  # S is a TypeVar with a `str` upper bound
-          ...
+          ...                    # We also say that S is bounded by str


      class StrOrBytesSequence[A: (str, bytes)]:  # A is a TypeVar constrained to str or bytes
          ...

Currently, the first time both expressions appear is in the following snippet. Perhaps adding just this small note would be enough?

   This syntax can also be used to create bounded and constrained type
   variables::

      class StrSequence[S: str]:  # S is a TypeVar with a `str` upper bound
-          ...
+          ...                    # We also say that S is bounded by str


      class StrOrBytesSequence[A: (str, bytes)]:  # A is a TypeVar constrained to str or bytes
          ...

That seems reasonable to me! Or maybe

   This syntax can also be used to create bounded and constrained type
   variables::

-      class StrSequence[S: str]:  # S is a TypeVar with a `str` upper bound
-          ...
+      class StrSequence[S: str]:  # S is a TypeVar with a `str` upper bound;
+          ...                     # we can say that S is "bounded by `str`"


      class StrOrBytesSequence[A: (str, bytes)]:  # A is a TypeVar constrained to str or bytes
          ...

I think I'm happy with it! Do I need to do anything else?

Thank you all for the very fast iteration!

I think I'm happy with it! Do I need to do anything else?

Not from my perspective! I'll wait a little while before merging, though, in case @JelleZijlstra or anybody else has any comments (there was quite a bit of discussion on the issue!)

All commit authors signed the Contributor License Agreement.

Oh wow I used GitHub's "accept suggestion" button, and now it created a commit with a different email address. Do I really need to sign the CLA again? Can I force-push changing that to my email address that had already signed the CLA?

EDIT: I guess it doesn't hurt to have the CLA signed from multiple addresses. Please tell me if having multiple addresses in the commit list is not desirable for any reason.

Oh wow I used GitHub's "accept suggestion" button, and now it created a commit with a different email address. Do I really need to sign the CLA again? Can I force-push changing that to my email address that had already signed the CLA?

EDIT: I guess it doesn't hurt to have the CLA signed from multiple addresses. Please tell me if having multiple addresses in the commit list is not desirable for any reason.

I'm pretty sure that should be fine :-)

Thanks @fofoni for the PR, and @JelleZijlstra for merging it 🌮🎉.. I'm working now to backport this PR to: 3.12, 3.13.
🐍🍒⛏🤖

No worries! We squash-merge so it doesn't really matter.

GH-126657 is a backport of this pull request to the 3.13 branch.

GH-126658 is a backport of this pull request to the 3.12 branch.