probablyrobert

Yes I am using the same approach however I am working on using native FFI bindings which is what the TypeScript client is using now.

https://github.com/RobertCraigie/prisma-client-py/pull/165

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

Thank you! I hope so too, it would be incredibly helpful.

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

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

Yes it is fully typed because of TypedDicts, https://docs.python.org/3/library/typing.html#typing.TypedDi...

SQLAlchemy on the other hand provides very little (if any) type hints for their query API.

You are correct, we use code generation to define the query API types.

Thanks for the feedback, I will add that.

> Prisma Python

I originally decided to go with Prisma Client Python however I found this to be too verbose and have recently used Prisma Python. I do need to decide on one and stick with that. Thanks for pointing that out

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

ORM stands for Object Relational Mapper and is essentially a wrapper over raw SQL queries to provide an easier to use interface.

Because Prisma Python currently interfaces with the Rust engine over HTTP (I am looking into changing this) and the Rust engines can be found here:

https://github.com/prisma/prisma-engines

I haven't written benchmarks yet but it is something I am working on. The reason that performance is mentioned in the README is that I haven't spent time on improving it yet.

The biggest blockers in terms of performance are:

- Communication with the internal Rust engine is performed over HTTP instead of FFI.

- You cannot select a subset of fields (every scalar field in a model is selected)

- You cannot skip pydantic validation which while fast is unnecessary in some cases

With that said Prisma Python should be reasonably fast but I would expect it to be on the lower end of the spectrum compared to other Python ORMs. I have ran some load tests locally and creating 500,000 records took about 90 seconds.

Good point, I'll update it, thanks!

Full disclosure, I am the creator of this project.

Happy to answer any questions!

Full disclosure - I am also the creator of this package.

Happy to answer any questions!