Pyspark on the other hand just sticks in my brain, somehow. Chained pyspark method calls looks much neater.
It's such a shame that python doesn't have a better DF library.
Base R is OK, but dplyr is magical.
For instance, integer indexing in base R is df[row,col] rather than the iloc pandas stuff.
plot, print and summary (and generic function OOP more generally is really underappreciated).
Python is a better programming language, but R is a better data analysis environment.
And dplyr is an incredibly fluent DSL for doing data analysis (not quite as good for modelling though).
Seriously, I read the original vignette for dplyr in late 2013/early 2014 and within two weeks I'd switched most of my new analytical code over to it. So very, very good. Less idea-impedance match than any other environment, in my experience.
1. Not so easy way to rename columns during aggregation
2. The group by generates its own grouped by data and hence you almost always need `reset_index`
3. Sometimes group by can convert a dataframe to series
4. Now `.loc` has provided bit consistent indexing/slicing, but earlier you had `.ix` `.iloc` and what not
These are something I can remember from top of my head. Of course all of these have solutions, but it makes pandas much more verbose. In R, these are just much more succinct.
https://www.rstudio.com/resources/rstudioglobal-2021/bringin...
Wait... I had no idea dplyr's database support was this good. https://db.rstudio.com/dplyr/
Essentially, `inplace=True` rarely actually saves memory, and causes problems if you like chaining things together. The people who maintain the library/populate the discussion boards are generally pro-chaining, so `inplace` is slowly and quietly on its way out.
The documentation should clearly say if the inplace argument causes an internal copy, because the availability of it implies that it doesn't. I've used inplace many times with Pandas because I've had code that I know is working with large amounts of data and I've thought "well I probably shouldn't chain these and cause tons of unnecessary allocations just to have prettier code".