use Postgres.py under the hood #41
Comments
|
Honestly, my immediate reaction is "I'm not sure", leaning towards "no". 1. Little/No Benefit: Records, as it stands, is a very thin layer on top of psycopg2, which, for the feature set that Records currently provides, is a perfect fit. In other words, I don't think moving to something else would provide any benefit at this time. 2. Other Databases: Also, there has been some consideration for adding support for other database backends. If we were to do this, it would likely be in the form of using SQLAlchemy as a database driver. So, relying on another Postgres library would take a step away towards that (currently non–) goal. 3. Too Early: That being said, at the moment, I'm deciding to stick with Postgres-only support (mostly because of very subtle differences in the way querys can be expressed in SQLAlchemy). I'm reconsidering it constantly, though, so this is further reason to not make any big dependency commitments at this time. |
|
Just pushed the release built on top of SQLAlchemy :D |
|
Alright. Good luck! :-) |
|
@whit537 😭 |
|
No worries. I think you just made DB-API 3.0, and I like it. :-) |
|
P.S. I would be remiss not to note that @3kwa ported the basic API from Postgres.py for other databases in https://github.com/3kwa/sql. |
|
@kennethreitz must be a better brand in the Python sphere. Thought of you @whit537 when I saw records pop all over the place. |
|
:-) |
|
I'm the Kanye West of Python. (That's my Kanye impersonation) |
|
Well, we're much less in competition now that Records is powered by SQLAlchemy. So, the sky's the limit! |
Mmmm ... over here it feels like we're much less in competition because Records has already nuked Postgres.py and sql out of the water in terms of open-source mindshare.
I'm not gonna say that doesn't burn a little bit, but branding and community matter at least as much as code, and you're purty good at all three. 😸 At the end of the day what really matters is that the Python community is finally getting a sane SQL API. 🍻 |
|
|
|
Wow does that mean sql is 1st in watch, star and fork 💃 |
Hah! You're the best around! 💃
Yeah, I finally ate crow on Aspen recently as well. Over there I never got the code to the level of polish I wanted, but I was actually really proud of Postgres.py. It was well-designed, well-documented, well-tested, ported to Python 3 ... tight! |
|
Hey! Here's another one called Queries from @gmr. I found it on http://awesome-python.com/ after googling for "postgres python for humans."
Looks like it's older than Postgres.py (initial commit on Queries is August 24, 2012, based on prior work; initial commit on Postgres.py is from Aug 7, 2013, based on internal Gittipay code going back to at least June 1, 2012). @gmr Looks like you came in second! Or third, depending on how we're counting it. ;-)
|
|
vinta/awesome-python#567 ← Postgres.py |
Over in Gratipay-land we've got a library called Postgres.py that has a very similar scope to Records-the-library (it has no CLI). It's been in production for three or four years, and as you say, it's "much more robust" than Records from an API point of view. I know you're opinionated about API design. I believe Postgres.py's API is worthy (or nearly so) of the "for Humans" appellation (and I'm not sure I didn't actually run that by you at some point in the past ;-).
I like the Tablib integration and CLI that I see here on Records, and our APIs are pretty close.
@kennethreitz Would you be open to a PR that switches Records to use Postgres.py under the hood? I'd envision keeping the CLI exactly the same. I think we'd need to talk through API—what gets wrapped, what gets exposed, what might be upstreamed.
Waddya say? Up for collaborating? :-)
The text was updated successfully, but these errors were encountered: