Open Bisaloo opened 4 weeks ago
Are there some edge cases one needs to be aware of?
list2DF()
doesn't recycle vectors whereas cbind.data.frame()
will. I think list2DF()
did recycle when first introduced but then became strict in a subsequent release.
x <- list(ind = 1:2, let = letters[1:6])
try(list2DF(x))
#> Error in list2DF(x) : all variables should have the same length
do.call(cbind.data.frame, x)
#> ind let
#> 1 1 a
#> 2 2 b
#> 3 1 c
#> 4 2 d
#> 5 1 e
#> 6 2 f
even length 1 not recycled
x <- list(ind = 1, let = letters[1:6])
try(list2DF(x))
#> Error in list2DF(x) : all variables should have the same length
do.call(cbind.data.frame, x)
#> ind let
#> 1 1 a
#> 2 1 b
#> 3 1 c
#> 4 1 d
#> 5 1 e
#> 6 1 f
In that case it makes it tough to recommend list2DF()
statically. OTOH, even just data.frame()
(which does do recycling) seems preferable?
I do see a surprising number of call sites for do.call(cbind.data.frame
:
So we could recommend just using data.frame()
instead, and mentioning list2DF()
as another alternative to consider if recycling is not needed?
Is there different behavior of data.frame()
vs. cbind.data.frame()
if the argument lists contain complex types such as data frames / matrices / lists?
Here's cbind.data.frame()
function (..., deparse.level = 1)
data.frame(..., check.names = FALSE)
<bytecode: 0x55bca92f06a0>
<environment: namespace:base>
:upside_down_face:
As an alternative to
do.call(cbind.data.frame, x)
.Created on 2024-06-07 with reprex v2.1.0
Some hits in the wild: https://github.com/search?q=org%3Acran+%2Fdo%5C.call%5C%28cbind%5C.data%5C.frame%2F&type=code
Are there some edge cases one needs to be aware of? Happy to submit a PR for this.