8000 TypeAliasType not raising TypeError when it is has no parameters · Issue #468 · python/typing_extensions · GitHub
[go: up one dir, main page]
Skip to content

TypeAliasType not raising TypeError when it is has no parameters #468

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
Daraan opened this issue Sep 25, 2024 · 1 comment · Fixed by #473
Closed

TypeAliasType not raising TypeError when it is has no parameters #468

Daraan opened this issue Sep 25, 2024 · 1 comment · Fixed by #473

Comments

@Daraan
Copy link
Contributor
Daraan commented Sep 25, 2024 •
edited
Loading

When using a TypeAliasType without type_params it should raise an error which it currently doesn't:

from typing import TypeAliasType as typing_TA
from typing_extensions import TypeAliasType

# this should raise an error
Simple = TypeAliasType("Simple", int)
Simple_typing = typing_TA("Simple", int)
try:
   Simple[str]  # No TypeError
except TypeError:
   print("TypeError raised like expected")
else:
   print("No type error was raised.")  # <-- will be printed

Simple_typing[str] # will raise TypeError

However, currently in 3.12+ when using type_params=() the code unexpectedly allows subscription.
See also cpython issue #124498 and its PR. This issue likely needs an upstream decision first if the following case is intended or a bug:

from typing import TypeAliasType as typing_TA
Simple2 = typing_TA("Simple", int, type_params=())
Simple2[str]  # no type error for typing.TypeAliasType

Also related:
@Daraan Daraan changed the title TypeAliasType not raising issue when it is parameterless TypeAliasType not raising TypeError when it is has no parameters Sep 25, 2024
@Daraan
Copy link
Contributor Author
Daraan commented Sep 25, 2024 •
edited
Loading

Currently the 3.13.0 typing.TypeAliasType variant passes the following tests:

    def test_subscription_without_type_params(self):
        Simple = TypeAliasType("Simple", int)
        with self.assertRaises(TypeError, msg="Only generic type aliases are subscriptable"):
            Simple[int]
        with self.assertRaises(TypeError, msg="Only generic type aliases are subscriptable"):
            Simple[[]]
        with self.assertRaises(TypeError, msg="Only generic type aliases are subscriptable"):
            Simple[()]
       
        # A TypeVar in the value does not allow subscription
        T = TypeVar('T')
        MissingTypeParamsErr = TypeAliasType("MissingTypeParamsErr", List[T])
        self.assertEqual(MissingTypeParamsErr.__type_params__, ())
        self.assertEqual(MissingTypeParamsErr.__parameters__, ())
        with self.assertRaises(TypeError, msg="Only generic type aliases are subscriptable"):
            MissingTypeParamsErr[int]
        with self.assertRaises(TypeError, msg="Only generic type aliases are subscriptable"):
            MissingTypeParamsErr[[]]
        with self.assertRaises(TypeError, msg="Only generic type aliases are subscriptable"):
            MissingTypeParamsErr[()]
            
        # However, providing type_params=() argument allows subscription
        MissingTypeParams = TypeAliasType("MissingTypeParams", List[T], type_params=())
        self.assertEqual(MissingTypeParams.__type_params__, ())
        self.assertEqual(MissingTypeParams.__parameters__, ())
        # These do not raise
        MissingTypeParams[int]
        MissingTypeParams[[]]
        MissingTypeParams[()]
        # These do not raise
        Simple2 = TypeAliasType("Simple2", int, type_params=())
        Simple2[int]
        Simple2[[]]
        Simple2[()]

EDIT: This behavior has now been changed and errors are raised like expected. #473 will align the behavior with the latest cpython implementation.

Daraan added a commit to Daraan/typing_extensions that referenced this issue Sep 25, 2024
@Daraan
Removed code addressing python#468
66eebb1
@Daraan Daraan mentioned this issue Sep 26, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
1 participant
@Daraan
0