I haven't used an ORM for some time (back when I programmed in Rails), but my experience and understanding is that an ORM largely replaces hand written SQL for a number of CRUD-style queries to manage object relational mapping for a persistence tier, and addresses a different issue than native vs SQL based operations in tabular environment such as as Pandas or R-dataframes.
I personally am not especially interested in recreating relational set operation using pandas operations. There are things I'd much rather do in pandas (such as summary statistics), and some things I'd much rather do in SQL elaborate JOINs and aggregations. I do admit there will be a grey area.
Interestingly, there are a lot of people who absolutely can't stand SQL, whereas I (and a lot of people) vastly prefer it.
As for ORMs - I actually did like them back when I did this sort of programming (managing the back and forth between objects and tables was honestly very boring), though once I was into reports, I often went straight to raw SQL. I no longer do that sort of work, and almost all code I now write is for analytical purposes, so I don't do any CRUD.
I have used pandas and the way it is used in Python is quite similar to how you would interface with the Django ORM.
Btw I've written lots of analytical types of queries using Django ORM (to power the backend for a dashboard API, for example). It is quite powerful. You can even do window functions and such directly with the ORM.
I'm having a little trouble understanding this - are you writing SQL to do the window function, or does the ORM provide a non-sql way to do the window function?
I'm using the ORM to do a window function, without writing any SQL directly. In fact I've done queries with several window functions, aggregations, and joins in a single query all from the ORM without writing any SQL. It is much easier to read and maintain than raw SQL too imo.
Ah. Well, that clearly works for a lot of people and sounds similar to how pandas works, though it's actually the opposite of what I'm describing here, which is the option to write SQL directly against a tabular data frames. For now, this is possible in Python through what I'd describe as out of the mainstream open source modules that are reputable and written by good programmers but may not be actively maintained. I get the impression that a sqldf in R is a bit more mainstream among R programmers, though I'm not sure of this.
What I'm talking about is this:
https://pandas.pydata.org/pandas-docs/stable/getting_started...
I personally am not especially interested in recreating relational set operation using pandas operations. There are things I'd much rather do in pandas (such as summary statistics), and some things I'd much rather do in SQL elaborate JOINs and aggregations. I do admit there will be a grey area.
Interestingly, there are a lot of people who absolutely can't stand SQL, whereas I (and a lot of people) vastly prefer it.
As for ORMs - I actually did like them back when I did this sort of programming (managing the back and forth between objects and tables was honestly very boring), though once I was into reports, I often went straight to raw SQL. I no longer do that sort of work, and almost all code I now write is for analytical purposes, so I don't do any CRUD.