Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for postponed evaluation of annotations #40

Open
ahopkins opened this issue May 2, 2019 · 3 comments
Open

Support for postponed evaluation of annotations #40

ahopkins opened this issue May 2, 2019 · 3 comments
Assignees
Labels
enhancement New feature or request question Further information is requested

Comments

@ahopkins
Copy link

ahopkins commented May 2, 2019

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.

@vltr
Copy link
Owner

vltr commented Jun 18, 2019

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 ...

@vltr vltr self-assigned this Jun 18, 2019
@vltr vltr added enhancement New feature or request question Further information is requested labels Jun 18, 2019
@ahopkins
Copy link
Author

I have not tried it... but does middle accept string annotations?

class Foo:
    bars: List["Bar"]

@vltr
Copy link
Owner

vltr commented Jun 18, 2019

I have not tried it... but does middle accept string annotations?

Nope, a str is a str (for now). I was thinking about:

class Foo:
    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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants