SQLAlchemy-core is not an ORM either, the ORM is based on it.
You can already write raw sql with it in a separate file if needed, and make a function out of it. I can't see a benefit to adding PugSQL on top of it, unless you plan to use the SQL from several languages.
Other than that, what will happen is that you will end up writing abstraction layers on top of it anyway. Gotta validate those data. Gotta provide a unified API to the rest of the program. And you will rewrite a poorly tested, less expressive sqlalchemy-core.
Not to mention you lose the benefit of being able to create a lib that can talk to several databases, code completion, linting, etc. That are much better in Python than SQL.
So, on one hand: full power of SQL if needed, plenty of additional features when not. On the other hand... what ?
That's what I love about Clojure culture. It started as an acknowledgment of weaknesses of dominant solutions (isn't ORM an anti-pattern?) and lead to this beautiful story of open source: Yesql -> HugSQL -> PugSQL
It's interesting to watch as it clashes here with one-way-of-doing-things Python culture.
Comments
This is not an ORM.
PugSQL is a Python incarnation of HugSQL, which was inspired by yesql, whose rationale you might want to read:
https://github.com/krisajenkins/yesql#rationale
SQLAlchemy-core is not an ORM either, the ORM is based on it.
You can already write raw sql with it in a separate file if needed, and make a function out of it. I can't see a benefit to adding PugSQL on top of it, unless you plan to use the SQL from several languages.
Other than that, what will happen is that you will end up writing abstraction layers on top of it anyway. Gotta validate those data. Gotta provide a unified API to the rest of the program. And you will rewrite a poorly tested, less expressive sqlalchemy-core.
Not to mention you lose the benefit of being able to create a lib that can talk to several databases, code completion, linting, etc. That are much better in Python than SQL.
So, on one hand: full power of SQL if needed, plenty of additional features when not. On the other hand... what ?
That's what I love about Clojure culture. It started as an acknowledgment of weaknesses of dominant solutions (isn't ORM an anti-pattern?) and lead to this beautiful story of open source: Yesql -> HugSQL -> PugSQL
It's interesting to watch as it clashes here with one-way-of-doing-things Python culture.