Безопасно ли использовать «df» в качестве имени для фрейма данных?

Question

Распространенная идиома (встречающаяся в книгах, учебных пособиях и по многим вопросам переполнения стека) заключается в использовании df в качестве своего рода одноразового идентификатора для кадра данных. Я делал это сотни раз без каких-либо неприятных последствий, но потом наткнулся на следующий код:

library(tree)
df <- droplevels(iris[1:100,c(1,2,5)])
tr <- tree(Species ~ ., data = df)
plot(tr)
text(tr)
partition.tree(tr)

Это дает следующее сообщение об ошибке:

Error in as.data.frame.default(data, optional = TRUE) : 
  cannot coerce class ""function"" to a data.frame

Я методом проб и ошибок обнаружил, что если я просто заменю df выше на df2, код будет работать, как и ожидалось. верно , что df - это название функции плотности для F-распределения, но здесь это не имеет никакого отношения к удалению. Это ошибка в пакете tree, или это важная предостерегающая история, мораль которой состоит в том, что я должен избегать использования df в качестве имени для фрейма данных, поскольку это приводит к конфликту имен?

Answer 1

Это ошибка в пакете дерева, или это важная предостерегающая история, мораль которой заключается в том, что я должен избегать использования df в качестве имени для информационного кадра, поскольку это приводит к конфликту имен?

Я думаю, что в этом случае это может быть и другое, но для ваших целей я бы взял это скорее как предостерегающий пример. Тот факт, что это вызывает ошибку, указывает на то, что это может быть не самой лучшей практикой.

По моему опыту, R не очень хорошо управляет пространствами имен (например, сравнивая его с Python). Из-за этого авторам дерева, возможно, было бы неразумно вводить (преднамеренно или нет) конфликт с df - обычным одноразовым именем для фрейма данных - если на самом деле они так и сделали (см. Комментарии здесь и в вопрос: неясно, является ли это конфликтом имен data.frame или неправильным использованием eval (), вызывающим конфликты между объектами и функциями data.frame).

С учетом сказанного, это хороший пример того, почему пространства имен важны и (IMO) наводит на мысль о том, как написать лучший R-код. Я думаю, что пространства имен вводятся в экосистему R, но мой опыт работы с R заключается в том, что существует много «плоскостности» пространства имен и много возможностей для конфликтов имен. По этой причине я хотел бы предложить, чтобы вы использовали это как причину, чтобы использовать больше описательных / уникальных идентификаторов для ваших собственных переменных. Это позволяет избежать конфликтов, подобных тому, с которыми вы столкнулись, и обеспечивает некоторую защиту от будущего, чтобы помочь избежать конфликтов, проникающих в ранее работающий код при изменении внутренних компонентов пакета.