gh-128661: Remove DeprecationWarning in evaluate_forward_ref

[JelleZijlstra]

It doesn't make sense to use a deprecation for evaluate_forward_ref,
as it is a new function in Python 3.14 and doesn't have compatibility
guarantees.

I considered making it throw an error if type_params it not passed and
there is no owner. However, I think this is too unfriendly for users. The
case where this param is really needed is fairly esoteric and I don't think
this case is worth the pain of forcing users to write "type_params=()".

• Issue: typing.evaluate_forward_ref is not fully covered #128661

---

📚 Documentation preview 📚: https://cpython-previews--128930.org.readthedocs.build/

[sobolevn]

cc @AlexWaygood who reviewed my PR.

[sobolevn]

My concern is that it would be rather easy to miss. This function has multiple parameters, __type_params__ is a new thing, which not many people are familiar with.

Proposed API makes it easy to miss.

And when missed, simple code like -> T and evaluate_forward_ref('T', format=VALUE) (instead of evaluate_forward_ref('T', format=VALUE, type_params=func.__type_params__)) can raise an error.

On the other hand, type_params is indeed optional in a sense, that users can't even provide type_params in all cases.

I have very mixed feelings about it :(

[JelleZijlstra]

In your example the user should rather pass owner=. Pointing them to use type_params= only makes the API more complicated.

[sobolevn]

Sorry, I am not yet fully familiar with this new API. Why do we even need type_params then, if it can be replaced with owner=? 🤔

[AlexWaygood]

Agree with @sobolevn. A DeprecationWarning obviously doesn't make sense, since it's a new function (sorry for missing that in the other PR). But I think you'll only know that you need to pass type_params explicitly when it starts failing with an inexplicable error that's really hard to debug. This feels like too much of a footgun to me :/