PEP 526 – Syntax for Variable Annotations

PEP 526, a significant milestone in Python's evolution, introduced a new syntax for variable annotations. This introduction will delve into the intricacies of this syntax, its implications, and its impact on Python's readability and efficiency.

This PEP aims at adding syntax to Python for annotating the types of variables (including class variables and instance variables), instead of expressing them through comments.

Since type comments aren’t actually part of the language, if a Python script wants to parse them, it requires a custom parser instead of just using ast.

Do not evaluate annotations, treat them as strings

Implement annotations as a descriptor

• Treating bare annotations the same as global or nonlocal
• Annotate variable types in class docstring
• TypeError will be raised if an attempt is made to update annotation when it is anything other than a mapping
• The presence of an annotation without assignment in a function body should not involve any evaluation

The majority of these issues can be alleviated by making the syntax a core part of the language.

Having a dedicated annotation syntax for class and instance variables will pave the way to static duck-typing as a complement to nominal typing defined by PEP 484

• Variable annotations are not designed for runtime type checking. Third party packages will have to be developed to implement such functionality.

Annotations for local variables will not be evaluated

Annotating a local variable will cause the interpreter to treat it as a local, even if it was never assigned to.

• The recommended way of getting annotations at runtime is by using typing.get_type_hints function; as with all dunder attributes, any undocummented use of annotations is subject to breakage without warning.

Types of locals and globals can be annotated

Being able to omit the initial value allows for easier typing of variables assigned in conditional branches

• Type annotations can also be used to annotate instance variables that should be initialized in init or new
• The proposed syntax is as follows: class BasicStarship:.
• Captain: str = ‘Picard’ while captain is an instance variable with a default value set in the class
• A ClassVar parameter cannot include any type variables, regardless of the level of nesting

Local annotations at function definition time

Store variable annotations also in function scope

• Initialize variables annotated without assignment
• Add also InstanceVar to the typing module
• Allow instance variable annotations only in methods
• Use syntax x: class t = v for class variables
• Forget about ClassVar altogether
• ClassAttr instead of ClassVar

Variable Annotations

Only single assignment targets and single right hand side values are allowed. Annotations for module level variables, class and instance variables, and local variables should have a single space after corresponding colon. There should be no space before the colon.

• If an assignment has left hand side, then the equality sign should have exactly one space on both sides of the assignment.

No:

A new covariant type ClassVar[T_co] is added to the typing module. It accepts only a single argument that should be a valid type, and is used to annotate class variables that should not be set on class instances.

• The function get_type_hints in the type module will be extended so that one can retrieve type annotations at runtime from modules and classes as well as functions.

Source