Sometimes a namedtuple, sometimes not

[NickDarvey]

I'm seeing an inconsistent behaviour where sometimes when I run my script, my typing.Tuple[] is detected as a named tuple and others time it is not.

That is, specifically, I can attach a debugger and see that this line sometimes evaluates true and sometimes false with zero changes to my script. Fun!

typeguard/src/typeguard/__init__.py

Line 494 in de6ab05

is_named_tuple = hasattr(expected_type, '__annotations__')

  File "/builds/work/areas/cloud/.venv/lib/python3.12/site-packages/aws_cdk/aws_iam/__init__.py", line 13910, in __init__
    check_type(argname="argument principals", value=principals, expected_type=typing.Tuple[type_hints["principals"], ...]) # pyright: ignore [reportGeneralTypeIssues]
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/builds/work/areas/cloud/.venv/lib/python3.12/site-packages/typeguard/__init__.py", line 757, in check_type
    checker_func(argname, value, expected_type, memo)
  File "/builds/work/areas/cloud/.venv/lib/python3.12/site-packages/typeguard/__init__.py", line 497, in check_tuple
    if not isinstance(value, expected_type):
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/typing.py", line 1195, in __instancecheck__
    return self.__subclasscheck__(type(obj))
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/typing.py", line 1198, in __subclasscheck__
    raise TypeError("Subscripted generics cannot be used with"
TypeError: Subscripted generics cannot be used with class and instance checks

Inspecting expected_type when it's not working:

> expected_type
typing.Tuple[aws_cdk.aws_iam.IPrincipal, ...]
  special variables
  function variables
  _determine_new_args: <bound method _GenericAlias._determine_new_args of typing.Tuple[aws_cdk.aws_iam.IPrincipal, ...]>
  _inst: False
  _make_substitution: <bound method _GenericAlias._make_substitution of typing.Tuple[aws_cdk.aws_iam.IPrincipal, ...]>
  _name: 'Tuple'

> getattr(expected_type, '__annotations__')
{}

> hasattr(expected_type, '__annotations__')
True

Inspecting expected_type when it is working:

> expected_type
  typing.Tuple[aws_cdk.aws_iam.IPrincipal, ...]
  special variables
  function variables
  _determine_new_args: <bound method _GenericAlias._determine_new_args of typing.Tuple[aws_cdk.aws_iam.IPrincipal, ...]>
  _inst: False
  _make_substitution: <bound method _GenericAlias._make_substitution of typing.Tuple[aws_cdk.aws_iam.IPrincipal, ...]>
  _name: 'Tuple'

> getattr(expected_type, '__annotations__')
Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/local/lib/python3.12/typing.py", line 1167, in __getattr__
    raise AttributeError(attr)
AttributeError: __annotations__

>hasattr(expected_type, '__annotations__')
False

If I do a dir(expected_type) the only difference is the addition of __annotations__ at position 0 in the failing case.

I'm sure there's not an issue with this library (plus this is using an old release (2.13.3)) but I was wondering if this behaviour sounds at all familiar and if you have any tips for where I should investigate?