You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Pep 563 defines the ability to lazily define type annotations.
Say I have something like this:
classFoo:
name: strclassBar:
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?
classBar:
foos: List[Foo]
classFoo:
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:
I think for middle it would be a relatively simple change, but it is a 3.7+ change. Just a thought.
It may be simple, yes, but I intend to support Python 3.6 yet for middle 0.3.x. I know that middle uses some metaclass magic and perhaps I could workaround that, but I feel this would not be possible since middle evaluates the classes during declaration - or I could lazily evaluate them as they are registered and replacing the defined classes in runtime. Hmmm, this does need some testing to see if it can be done with Python 3.6 and would not break evaluation ...
I have not tried it... but does middle accept string annotations?
Nope, a str is a str (for now). I was thinking about:
classFoo:
bars: List[middle.lazy("Bar")]
Instead of the lazy annotations, but this will fall into the same problem as I mentioned earlier: lazily evaluate the entire class only when all classes are available and reload them inside sys.modules ... A bit hacky, I don't know if it'll work properly but it'll be almost the same thing as the metaclass making this magic (I guess).
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
middle
it would be a relatively simple change, but it is a 3.7+ change. Just a thought.The text was updated successfully, but these errors were encountered: