Hacker News Reader

Comment by dragonwriter | Hacker News Reader

You can create Python types at runtime, and Python’s runtime type checking features predate it's static analyzers. Unfortunately, the additional kinds of objects used for typechecking in the static analyzers (beyond those which are also runtime types) don’t work with runtime type checking, nor do static type declarations (even using types that are also runtime types.) (And, obviously, AOT static analyzers can’t make use of types that don’t exist when they run.)

View on HN

Exactly, it’a brilliant that they designed a system where the annotations themselves can be dynamic and read at runtime, it has so much potential for interesting things. But MyPy completely hobbles it by preventing all the dynamic potential, even if MyPy had an escape hatch to say ignore anything derived from this type as it’s not possible to describe statically that would be better than nothing.

It unfortunately leaves you with a choice of either taking advantage of dynamic annotations or using MyPy, but not both.

And as the sibling comment says, typescript did it so much better.

There is actually an escape hatch you can use, although it is a bit clunky:

    ```py
    from typing import TYPE_CHECKING

    if TYPE_CHECKING:
        Foo = "expression that mypy can understand"
    else:
        Foo = "dynamic expression"
    ```

Somehow in all my searching the other day I missed that, thanks!

Python also offers structural typing, which is both dynamic and mypy-compatible.

I have also written a python ORM, Bozen[1]. In Bozen you define a table like this:

    class Book(MonDoc):
        title = StrField()
        yearPublished = IntField()

Is it possible to give run-time types to `title` and `yearPublished`, in a way that works with mypy and the Python typing ecosystem? If so, is there a tutorial on this, as I'd like to add the feature to my ORM.

1: https://github.com/cabalamat/frambozenapp

The most obvious way would be to simply annotate the fields, e.g.

  class Book(MonDoc):
    title: str = StrField()
    yearPublished: int = IntField()

If this means too much redundant information for you then you could try defining the fields to return the corresponding python type e.g.

  def IntField() -> int:
    ...

I could certainly annotate the fields like you suggest. But that goes against the spirit of Bozen which is DRY.

When I define something as a `StrField` I'm already saying it's a string, so I shouldn't have to say it again elsewhere. It would be nice if Python has an API such that I can write code within my `StrField` class that tells python that `title` is a `str`, but to the best of my understanding this doesn't exist.

Yes it is rather unfortunate, Python's typing system doesn't support dynamically creating types like you can in TypeScript :/

> dynamically creating types

Could you explain what you mean by this? I'm not clear on what typescript behavior this describes.

Maybes mapped types are an example? https://www.typescriptlang.org/docs/handbook/2/mapped-types....

Yes mapped types is a good example, Pick is also a good example:

https://www.typescriptlang.org/docs/handbook/utility-types.h...

Ah, I read "dynamic" as implying something at runtime. I agree that these are extremely useful.

Reply on news.ycombinator.com