将变量存储为另一个变量的属性是一种好习惯吗？答案

【问题标题】：Is it good practice to store variables as attributes of another variable?将变量存储为另一个变量的属性是一种好习惯吗？
【发布时间】：2018-11-29 18:01:30
【问题描述】：

我最近开始将变量（例如 X_train、y_train、X_test、y_test）存储为其完整数据帧的属性。当我同时使用多个数据集时，它帮助我组织了不同的训练和测试数据集。这通常被认为是好的/好的做法吗？这是一个例子：

我最初的学习方式是：

X_train, X_test, y_train, y_test = train_test_split(some_dataframe[features],\
    some_dataframe[target]

我最近开始做的方式：

some_dataframe.X_train, some_dataframe.X_test,\
    some_dataframe.y_train, some_dataframe.y_test = \
    train_test_split(some_dataframe[features], some_dataframe[target]

【问题讨论】：

我对你在问什么感到困惑。 some_dataframe.X_train 是 pandas 引用列的语法
我认为您对“方法”和“属性”之间的区别也有一些混淆，这使您不太清楚您在问什么。我认为我们需要更多代码来准确理解您正在实施的内容。请提供MCVE
我更喜欢由具有这些其他属性的 df 组成的包装类。
好点@roganjosh，实际上熊猫数据框不是“常规 python对象”，因为它具有人们期望的一些补充属性。通过在此处添加属性，您有点打破了 pandas 数据框附带的“合同”。所以你有一个非常好的理由这样做......
@roganjosh 这不是语法或任何内容的模糊。数据框可能会重载其__getattr__ 以检查属性是否对应于列，然后返回它，或者引发属性错误。但是设置一个属性仍然可以像任何其他 python 对象一样工作。 为什么他们这样做了，嗯，可能是因为对于数据分析的用例，它派上用场了。许多非软件工程师使用pandas 仅用于数据分析，而不是构建质量代码库

标签： python pandas dataframe variables storage

【解决方案1】：

tl;dr：如果您找不到真正充分的理由，请避免合并。

我认为你正在做的事情是所谓的“坏机会”的一部分。

由于我无法了解您选择背后的所有细节，我并不是说这是一个坏主意，但您对问题的描述似乎指出了将不同数据源合并在一起的常见问题。

你想要的是重新组合你的所有数据在一个数据结构中，以将它们与其他数据源区分开来，所以我猜你想为什么不使用已经可用的东西，为什么不使用这个我刚刚使用的“模糊相关”的数据框？

但是您应该问自己，为什么 this 数据结构与您想要实现的目标相关？是什么使它成为正确的数据结构？您是否要将此 df 的先前数据与新数据一起使用？或者你只是因为它“在那里”而选择了这个结构？

如果你没有理由专门使用这个数据框，我会简单地创建一个新的数据结构，可能一个字典就足够了。在您的具体情况下，一些原因是：

数据框可能超出了您正在查找的内容。
通过将不同的东西放在一起，您失去了先前数据框的一些不错的属性（例如，您的数据框现在的尺寸是多少？有多少行？）
人们/您可能会对数据框的不同部分感到困惑。例如，当您将改变您的数据时，您确定您将知道转换将应用于哪些数据吗？你会记得哪些数据是“原始”数据框的一部分以及之后添加了什么？

总而言之，将不同的数据（或一般的想法）融合到一个结构（概念）中总是有风险的，你应该总是有充分的理由这样做，而不仅仅是因为你可以。

PS：请参阅@roganjosh 在 cmets 中提出的问题，这些问题很好地说明了当您开始将原本不应该存在的东西放在一起时出现的问题。

【讨论】：

我认为你是对的。但一个小的更正 - 添加一个属性不会改变原始数据框。因此您的原始数据保持不变，但您可以访问更改后的数据框作为原始数据框的属性。
@JoeB 在技术上做得很好，因为它仍然是同一个对象，但现在你只是在旁边加上了一个属性。如果我继承了一个代码库，只是看到 some_dataframe.X_train 漂浮在周围，然后我发现它是一个附加属性而不是 DataFrame 列的语法，我不情愿地来到接受，我不会太高兴的。我认为重点是我们对语法所代表的内容有一些期望，而不是试图说现有数据以任何方式发生了变化