Pep 563 defines the ability to lazily define type annotations.
Say I have something like this:
class Foo:
name: str
class Bar:
foos: List[Foo]
This would work fine. But what if I am importing from another library, or have them in defined in a different order?
class Bar:
foos: List[Foo]
class Foo:
name: str
This will break.
Pep 563 addresses this with from __future__ import annotations. Basically it passes the type annotation as a string to then be resolved at runtime with: typing.get_type_hints().
Therefore, rather than grabbing self.__annotations__, you do something like what I did in pydiggy:
annotations = get_type_hints(self, globalns=globals(), localns=localns)
I think for middle it would be a relatively simple change, but it is a 3.7+ change. Just a thought.
Pep 563 defines the ability to lazily define type annotations.
Say I have something like this:
This would work fine. But what if I am importing from another library, or have them in defined in a different order?
This will break.
Pep 563 addresses this with
from __future__ import annotations. Basically it passes the type annotation as a string to then be resolved at runtime with:typing.get_type_hints().Therefore, rather than grabbing
self.__annotations__, you do something like what I did inpydiggy:I think for
middleit would be a relatively simple change, but it is a 3.7+ change. Just a thought.