annotationlib.ForwardRef.__hash__ raises TypeError on an unhashable value

[tonghuaroot]

annotationlib.ForwardRef defines both __eq__ and __hash__, but __hash__
raises TypeError when the forward reference holds an unhashable value, even
though two such forward references compare equal. This violates the data model
(objects that compare equal must be hashable and hash equal) and breaks storing
forward references in sets or as dict keys, which typing tools do.

Reproducer

from annotationlib import Format, get_annotations

class Unhashable:
    __hash__ = None

obj = Unhashable()

def f(a: undefined | obj): ...

fr1 = get_annotations(f, format=Format.FORWARDREF)["a"]
fr2 = get_annotations(f, format=Format.FORWARDREF)["a"]
assert fr1 == fr2
hash(fr1)   # TypeError: unhashable type: 'Unhashable'

obj resolves as a global, so the FORWARDREF format stores it in the forward
reference's __extra_names__. The same happens when the forward reference's
__owner__ is unhashable, for example a class whose metaclass sets
__hash__ = None.

Root cause

ForwardRef.__hash__ already hashes the unhashable __globals__ and __cell__
fields by identity (id()), but __owner__ and __extra_names__ are hashed
directly. __extra_names__ holds arbitrary values embedded in an annotation
that the FORWARDREF format could not render as a plain name, so those values
may be unhashable.

Regression

This is a sibling of #143831, which fixed the same class of bug for __cell__.
The traceback in that report already pointed at the __extra_names__ line.

Affected versions

3.14+ (where annotationlib was added).

Linked PRs

• gh-152358: Fix hash() of annotationlib.ForwardRef with unhashable value #152360

[johnslavik]

Thanks for the report.

This violates the data model (objects that compare equal must be hashable and hash equal) and breaks storing forward references in sets or as dict keys, which typing tools do.

Objects used in annotations are usually hashable. It's always best to include a reproduction that demonstrates a realistic user intent and how the reported bug prevented the user from implementing that intent. This makes it easier to assess the use case and the behavior, find workarounds, etc.

How did you find this? The only realistic case I can think of is something like

>>> from typing import Annotated
>>> from annotationlib import get_annotations, Format
>>>
>>> def f(x: Annotated[T, {"some": "metadata"}]):
...     pass
...
>>> runtime_type_info = {get_annotations(f, format=Format.FORWARDREF)["x"]: ...}  # fails
Traceback (most recent call last):
  File "<python-input-18>", line 1, in <module>
    runtime_type_info = {get_annotations(f, format=Format.FORWARDREF)["x"]: ...}
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: cannot use 'typing._AnnotatedAlias' as a dict key (unhashable type: 'dict')
>>> def f(x: int):
...     pass
...
>>> runtime_type_info = {get_annotations(f, format=Format.FORWARDREF)["x"]: ...}  # succeeds

cc @JelleZijlstra, should we extend ForwardRef.__hash__ to cover such cases?