You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
a single character string containing comma separated column names
...but here the help text is more informative than for key: it's explicit about the possibility for leading or trailing spaces in column names (although I think that would be a terrible habit):
where spaces are significant since column names may contain spaces even at the start or end
In addition, I find the error message in by slightly clearer: because the problematic column name is quoted in the error message, it's easier to spot a space here than in the corresponding error message for key, where the name is unquoted.
as.data.table(mtcars)[ , .N, by = "vs, am"]
# Error in eval(bysub, x, parent.frame()) : object ' am' not found
I think that the specification of column names using "a single character string containing comma separated column names" should behave similarly in key and by. That said, I wouldn't miss this option to specify columns if it was deprecated.
I would not use .(), then we don't need to substitute. And personally I would deprecate scalar string for multiple columns, both in key and in by, of course very slowly.
@shrektan I do not follow. Not sure if there is a question about a column name containing a comma. But some column names do sometimes have white space.
@jangorecki using substitute is 5 times slower - it takes 2.6 microseconds. In the long run I still see the col_select being able to be used in situations like these.
Activity
Henrik-P commentedon Mar 10, 2020
Please note that also
byalso accepts...but here the help text is more informative than for
key: it's explicit about the possibility for leading or trailing spaces in column names (although I think that would be a terrible habit):In addition, I find the error message in
byslightly clearer: because the problematic column name is quoted in the error message, it's easier to spot a space here than in the corresponding error message forkey, where the name is unquoted.I think that the specification of column names using "a single character string containing comma separated column names" should behave similarly in
keyandby. That said, I wouldn't miss this option to specify columns if it was deprecated.ColeMiller1 commentedon Mar 10, 2020
I agree with @Henrik-P. A better way may be to export the
.()functionality which would take one more character to do what you are proposing.FWIW, I am going to propose to deprecate the comma delimited feature in the
byarg in another PR. I'll make a separate issue for that discussion.jangorecki commentedon Mar 10, 2020
I would not use .(), then we don't need to substitute. And personally I would deprecate scalar string for multiple columns, both in key and in by, of course very slowly.
shrektan commentedon Mar 10, 2020
ColeMiller1 commentedon Mar 11, 2020
@shrektan I do not follow. Not sure if there is a question about a column name containing a comma. But some column names do sometimes have white space.
@jangorecki using
substituteis 5 times slower - it takes 2.6 microseconds. In the long run I still see thecol_selectbeing able to be used in situations like these.Actual benchmark data
MichaelChirico commentedon Jul 11, 2025
I would consider
key=<string>support in maintenance mode -- we don't really plan to deprecate it, but neither will we do more feature work like this.