[PYTHON] I read PEP 613 (Explicit Type Aliases)

I've been following python / peps recently to follow PEP updates, but GvR is [PEP 613 (Explicit Type Aliases)](https: / /www.python.org/dev/peps/pep-0613/) said something like putting it in 3.10 (instead of 3.9) so I read it a bit.

I think it’s too late to add to 3.9, but it can be added to typing_extensions, and of course 3.10 is open (the master branch is now 3.10). https://github.com/python/peps/issues/1412#issuecomment-633641359

Overview

• PEP-484 (Type Hints) mentions the existence of type aliases, but details how to define them. Did not
• For now, ** global variables ** and ** variables without type hints ** are considered type aliases.
• Forward Reference Problems and scope problems tend to occur
• So I'll be able to explicitly define type aliases
• You can still define implicit type aliases
• The status is Accepted so it will be implemented eventually (probably 3.10)

approach

• Add a new typing.TypeAlias
• When defining a type alias, write a variable of type alias type like T: TypeAlias = int
• Consider variables defined at the global level as type aliases
• You may write T: TypeAlias =" int " when doing ForwardReference

Example

In the explicit grammar, it is treated as follows.

#Just a global variable
x = 1
x: int = 1

#Just a global variable
x = int
x: Type[int] = int

#Type alias
x: TypeAlias = int
x: TypeAlias = “MyClass”

Impressions

• Considering Forward Refernece, it was necessary to treat a simple string string constant as ** may point to a type **, but now it can be written semantically with explicit syntax.
• However, it doesn't mean that the implicit syntax is gone, so it doesn't change anything.
• For users, it is safe to add the TypeAlias type for the time being.
• However, its implementation is (at the earliest) from 3.10, so it will be available after next fall ...
• I understand the reason, and I have no reason to oppose it, but I only have the feeling that it will not be used because it is too late to come out.
• I haven't confirmed the operation, but it seems that it is already implemented in pyre?