New Features¶ PEP 563: Postponed Evaluation of Annotations (JNNC Technologies)

http://jnnctechnologies.com/

https://clanguagetraininginvizagjnnc.blogspot.com/

https://javatrainingjnnctechnologies.blogspot.com/

https://pythontraininginjnnctechnologies.blogspot.com/

https://dotnetjnnctechnologies.blogspot.com/

https://softwarecoursesselenium.blogspot.com/

https://jnnc-technologies-pvtltd-software-training-institute.business.site/?

https://summerinternshipinjnnctechnologies.blogspot.com/

https://www.google.com/maps/place/JNNC+Technologies+Pvt.Ltd/@17.725503,83.3016408,17z/data=!3m1!4b1!4m5!3m4!1s0x0:0xd8a1b115babeb73c!8m2!3d17.725503!4d83.3038295

The advent of type hints in Python uncovered two glaring usability issues with the functionality of annotations added in PEP 3107 and refined further in PEP 526:

annotations could only use names which were already available in the current scope, in other words they didn’t support forward references of any kind; and
annotating source code had adverse effects on startup time of Python programs.

Both of these issues are fixed by postponing the evaluation of annotations. Instead of compiling code which executes expressions in annotations at their definition time, the compiler stores the annotation in a string form equivalent to the AST of the expression in question. If needed, annotations can be resolved at runtime usingtyping.get_type_hints(). In the common case where this is not required, the annotations are cheaper to store (since short strings are interned by the interpreter) and make startup time faster.

Usability-wise, annotations now support forward references, making the following syntax valid:

class C:
    @classmethod
    def from_string(cls, source: str) -> C:
        ...

    def validate_b(self, obj: B) -> bool:
        ...

class B:
    ...