Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Prisma Python – A fully typed ORM for Python

github.com

Post reply on HN
Print view View original

21–30 of 91 posts

Re: Show HN: Prisma Python – A fully typed ORM for Python

#21

Post by dragonwriter »

samwillis wrote: post #14

> 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 automatically create types at runtime (which is actually super annoying, particularly for a language as dynamic as Python).

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

Re: Show HN: Prisma Python – A fully typed ORM for Python

#22

Post by klft »

Seems to solve the same problem as SQLModel.

From [1]: "SQLModel is a library for interacting with SQL databases from Python code, with Python objects. It is designed to be intuitive, easy to use, highly compatible, and robust.

SQLModel is based on Python type annotations, and powered by Pydantic and SQLAlchemy."

[1] https://sqlmodel.tiangolo.com/

Re: Show HN: Prisma Python – A fully typed ORM for Python

#23

Post by probablyrobert »

klft wrote: post #22

Seems to solve the same problem as SQLModel. From [1]: "SQLModel is a library for interacting with SQL databases from Python code, with Python objects. It is designed to be intuitive, easy to use, highly compatible, and robust. SQLModel is based on Python type annotations, and powered by Pydantic and SQLAlchemy." [1] https://sqlmodel.tiangolo.com/

Yes it is similar to SQLModel however as SQLModel is based off of SQLAlchemy, the query API is not typed. That is the difference.

Re: Show HN: Prisma Python – A fully typed ORM for Python

#24

Post by probablyrobert »

dragonwriter wrote: post #21
samwillis wrote: post #14

> 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 automatically create types at runtime (which is actually super annoying, particularly for a language as dynamic as Python).

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…

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

Re: Show HN: Prisma Python – A fully typed ORM for Python

#25

Post by lytefm »

probablyrobert wrote: post #12
lytefm wrote: post #10

This looks promising. Using prisma both in TypeScript app backends and in Python data pipelines would make switching between the two without much cognitive overhead much easier. I'll probably oppose introducing a different Python ORM at work until Prisma Python reaches 1.0

Thanks :) Yeah that is understandable, it is being successfully used in production but it is safer to use a more stable ORM for mission critical products. If you don't want to have to duplicate your model definitions you could write a custom Prisma Generator to generate models for a different Python ORM. https://prisma-client-py.readthedocs.io/en/stable/reference/...

Nice, sharing the models across Codebases but only doing the migrations on one side is definitely what I'd be looking for.

Re: Show HN: Prisma Python – A fully typed ORM for Python

#26

Post by samwillis »

dragonwriter wrote: post #21
samwillis wrote: post #14

> 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 automatically create types at runtime (which is actually super annoying, particularly for a language as dynamic as Python).

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…

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.

Re: Show HN: Prisma Python – A fully typed ORM for Python

#29

Post by probablyrobert »

samwillis wrote: post #26
dragonwriter wrote: post #21

Earlier quoted context omitted.

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…

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 lea…

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"
    ```

Re: Show HN: Prisma Python – A fully typed ORM for Python

#30

Post by dllthomas »

probablyrobert wrote: post #24
dragonwriter wrote: post #21

Earlier quoted context omitted.

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…

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.

Post reply on HN