pdeffebach

This would be great to have. We still have the problem with `GroupedDataFrame` iterating through groups, so we get a conflict with `Base`.

But because a `GroupedDataFrame` iterates through groups, to keep a contract with `Base`, `sort` should sort groups.

Okay. If we implement this then I would deprecate `@orderby` and scrap plans for the `GroupedDataFrame` case. I would still want `where` to perform transformations by groups. That seems more...

As mentioned in DataFramesMeta [here](https://github.com/JuliaData/DataFramesMeta.jl/pull/191#issuecomment-711016253). For consistency with `Base` and `filter` it might make sense to `sort` transformations to operate on rows. And `sort` to operate on grouped data frames...

one problem is that this would create a new column in the data frame, right? Is there some extra step we can use to delete the created column? EDIT: It...

I say go for it. This will bring more consistency with the API and allow DataFramesMeta to deprecate `@orderby` in favor of `@sort`.

+1 to this. I think it would be a great feature to have. I don't fully understand why we can't do ``` sort(df, :x => fun1, :y => fun2) ```...

I am generally in favor of adding more `!` arguments because some times you don't want to think of a new name, or don't want to do everything in a...

This also seems nice. Tables.jl has a row type which prints like a named tuple. We could change upstream and copy their printing as well.

Interestingly, it's different for `select` ``` julia> @time select(df, [:a, :b] => ((@nospecialize args...) -> begin a, b = args @. a + b * a * b end) =>...