6 ms·

> by auto-generating python types I'm assuming you are using a code generator? My understanding is that as MyPy is a static analyser there is no way to automat

• probablyrobert 5y ago
  You are correct, we use code generation to define the query API types.
• dragonwriter 5y ago
  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.)
  • probablyrobert 5y ago
    Yes it is rather unfortunate, Python's typing system doesn't support dynamically creating types like you can in TypeScript :/
    • dllthomas 5y ago
      > dynamically creating types Could you explain what you mean by this? I'm not clear on what typescript behavior this describes.
      • joshribakoff 5y ago
        Maybes mapped types are an example? https://www.typescriptlang.org/docs/handbook/2/mapped-types.html https://www.typescriptlang.org/docs/handbook/2/mapped-types....
        • probablyrobert 5y ago
          Yes mapped types is a good example, Pick is also a good example: https://www.typescriptlang.org/docs/handbook/utility-types.html#picktype-keys https://www.typescriptlang.org/docs/handbook/utility-types.h...
          • dllthomas 5y ago
            Ah, I read "dynamic" as implying something at runtime. I agree that these are extremely useful.
  • samwillis 5y ago
    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.
    • probablyrobert 5y ago
      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" ```
      • samwillis 5y ago
        Somehow in all my searching the other day I missed that, thanks!
    • BerislavLopac 5y ago
      Python also offers structural typing, which is both dynamic and mypy-compatible.
  • cabalamat 5y ago
    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 https://github.com/cabalamat/frambozenapp
    • probablyrobert 5y ago
      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: ...
      • cabalamat 5y ago
        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.