Pandas: ENH：允许通过 I/O 例程的关键字选择 I/O 例程上的新数据类型

@jorisvandenbossche这可能适用于 1.0 吗？ 我最初的偏好是在将来添加它（作为 1.1 中的一个选项说）

它当然不是关键发布，所以让我们从里程碑中删除。

那么知道我们想如何解决这个问题吗？ 我认为构造函数（例如DataFrame(..) ）也可以使用类似的选项。

像use_new_dtypes=True/False这样的选项在创建数据帧/系列的函数中始终如一？
或者更好的名称，因为“新”不是很具有描述性。 use_nullable_dtypes可能无法完全覆盖例如字符串，因为它们之前已经可以为空。

我想争辩说，如果您想让人们使用新的 dtype，尤其是pd.NA ，那么这变得非常重要，因为恕我直言，大多数缺失值都是在人们读取数据时引入的。 因此，如果您不更改 I/O 例程，则不太可能使用pd.NA 。

至于名字，也许use_extension_dtypes ??

我不喜欢use_extension_dtypes一点是它听起来像是 pandas 的扩展，但在这里并非如此。 希望在某些时候这些是默认的 dtypes。
（我知道，整个事情都被称为扩展......，但仍然如此）。

use_distinct_dtypes怎么样？

@jorisvandenbossche我开始研究这个，如果我们为每个读者都这样做，由于所有不同的读者实现，它最终可能会做很多工作。 这是另一个提议。 如果我们创建一个方法DataFrame.as_nullable_types() ，它会接受DataFrame并将它可能的任何列转换为可空类型。 然后，如果您使用任何未使用新类型的阅读器，您可以在一行中转换整个DataFrame ，因此您可以拥有df = pd.read_csv('filename.csv').as_nullable_types()或df = pd.read_excel('filename.excel').as_nullable_types()等. 规则可能是这样的：

1. 如果 dtype 是对象，则转换为字符串。 如果失败，就别管它。
2. 如果 dtype 是 float，请尝试转换为 boolean。 如果失败，请尝试转换为 Int64。 如果失败了，就别管它了。

我的目标是让人们更容易使用新的StringDType 、 Int64DType和BooleanDType 。 如果我们不做这样的事情，我认为这些类型不会得到锻炼，因为在读取数据时通常会遇到缺失值，并且在读取大量数据时必须为每一列指定 dtype 是很痛苦的列。

如果我们为每个读者都这样做，由于所有不同的读者实现，它最终可能会是很多工作

我想，如果我们想拥有有效的方法，无论如何我们可能需要最终实现特定于读者的实现。 但是，这当然并不意味着所有的读者都需要原生支持，我们可以从重要的开始，让其他人阅读后转换。 例如，我计划在一个镶木地板阅读器上工作，它直接为您提供可为空的整数（这避免了复制和不必要的浮动往返）。 总而言之：我认为在某些情况下将其作为阅读器选项仍然很有用。

但这就是说，使用可空类型将现有数据帧转换为新数据帧的辅助方法/函数听起来是个好主意，无论如何这都会很有用。
从概念上讲，它有点类似于DataFrame.infer_objects （“尝试为对象列推断更好的 dtypes。”，除了这里我们想为所有列推断更好的 dtypes）

@jorisvandenbossche我将研究辅助方法，因为我认为它应该在 1.0 中，然后我们可以弄清楚如何为更高版本更改各种读取器（以及更改顺序）。

我提出了一个 PR 为read_parquet实现了一个use_nullable_dtypes选项： https :

在向read_parquet添加一个选项的 PR 中，我们正在讨论关于 IO 中的此类选项越来越笼统，以及对此类选项的期望（不仅是名称）更笼统，所以把它移到这里。

@jreback和@WillAyd提到他们更喜欢use_extension_dtypes不是use_nullable_dtypes ，我回答说：

对我来说，不使用use_extension_dtypes主要原因是：1）此选项通常不会触发返回扩展 dtypes。 例如，它不会触发返回 categorical 或 datetimetz（因为它们默认由 pyarrow 返回），并且它不会触发返回 period 或 interval（可以根据保存在 parquet 文件 / pyarrow 扩展中的元数据返回）类型）； 在这两种情况下，即使使用use_extension_dtypes=False也会返回扩展类型。 相比之下，我发现use_nullable_dtypes在传达意图时更清晰*。
此外，在语义上，“扩展”类型可以提供关于“外部”扩展类型的概念（但这通常是该术语的一个问题，因此与此处无关）。

*我认为我们将需要一些术语来表示“使用pd.NA作为缺失值指示符的 dtypes” 。 也为了我们关于它的交流（和讨论时），因为在文档等中，最好有一个我们可以一直使用的术语。 我认为“可为空的 dtypes”是一个选项（我们已经在文档中使用了一段时间的“可为空的整数 dtype”），虽然肯定不理想，因为严格来说其他 dtypes 也是“可为空的”（浮点数、对象、日期时间） ，只是方式不同。
也许进行这个更一般的讨论可以帮助我们之后找到匹配的关键字名称。

@WillAyd 的回复

当然是一些快速的反驳论点：

• 最终用户不清楚语义； 我认为大多数人认为 np.float 可以为空，这不会影响
• 其清晰度的一些论点是特定于镶木地板的，但我认为如果我们为其他解析器重用相同的关键字（我希望我们会这样做），就会变得更加模棱两可
• 如果我们将来添加更多的扩展类型，而不仅仅是专注于 NA 处理，那么我们必须在此之上添加另一个关键字来解析，这只会使事情变得更加复杂

第三点可能是我认为最重要的一点

_回复@WillAyd_

• 如果我们将来添加更多的扩展类型，而不仅仅是专注于 NA 处理，那么我们必须在此之上添加另一个关键字来解析，这只会使事情变得更加复杂

第三点可能是我认为最重要的一点

我同意这是不使用as_nullable_dtypes一个令人信服的论点。 这里有一些想法：

• as_NA_dtypes （支持pd.NA ）
• as_modern_dtypes （因为我们想要支持的任何东西都是最现代的）
• as_endorsed_dtypes （然后我们可以确定哪些是认可/推荐的）

希望能引起讨论！

感谢@WillAyd的这些论点。 由此看来，我们似乎仍然需要讨论/澄清我们想要通过这样的选项实现的确切目的

最终用户不清楚语义； 我认为大多数人认为 np.float 可以为空，这不会影响

是的，这就是我提到的“可空”不理想。 但这是谈论这些 dtype 的普遍问题。 如上所述，我认为我们需要为此找到一些术语。
如果我们在文档中明确定义“可为空 dtype”的含义，并为此目的在整个文档中一致使用它，我认为这样的术语可以工作（IMO，它至少比没有一致的术语要好）。
此外，在某些时候，我们可能想要一个使用pd.NA作为缺失值的 float dtype。 那么我们也需要一个术语来将它与“经典”浮点型（“可为空的浮点型”？）

其清晰度的一些论点是特定于镶木地板的，但我认为如果我们为其他解析器重用相同的关键字（我希望我们会这样做），就会变得更加模棱两可

Parquet 是具有最多类型信息的格式之一，因此通常的扩展类型和特定的可空类型之间的区别确实是最相关的。 在阅读例如 csv 时，您确实无法获得分类。 但它并不完全限于镶木地板。 read_feather和read_orc也是基于 pyarrow 的，因此具有相同的类型支持。 您可以从read_stata和read_spss获得分类，您可以从read_sql和（也许？） read_excel获得 datetimetz

如果我们将来添加更多的扩展类型，而不仅仅是专注于 NA 处理，那么我们必须在此之上添加另一个关键字来解析，这只会使事情变得更加复杂

是的，如果这些新的扩展类型不使用 pd.NA 作为缺失值指示符，它们将故意不属于这个关键字。 这里的这个问题实际上是关于那些使用 pd.NA 的 dtypes，因为它们对于涉及缺失值的操作有不同的行为。
现在，我个人认为我们不应该添加不使用pd.NA新扩展数据类型，但这是另一个讨论。 讨论这样一个假设的案例也很困难； 出现的一个具体示例是 struct/json 之类的东西：无论如何，这些可能无法以典型的文件格式存储（而且，我们可能会使用 pd.NA 作为缺失值）。

如果我们将来添加更多的扩展类型，而不仅仅是专注于 NA 处理，那么我们必须在此之上添加另一个关键字来解析，这只会使事情变得更加复杂

第三点可能是我认为最重要的一点

我同意这是不使用 as_nullable_dtypes 的一个令人信服的论点。

为了强调我上面长篇文章中关于这方面的回答的一点：IMO，如果这样的新 dtype 不使用 pd.NA，它不应该属于这个关键字。 因此，如果我们这样做（当然有争议），那么无论我们使用什么名称（例如use_NA_dtypes ）都会遇到完全相同的问题。

方向略有不同，但默认情况下像na_float_cast=True这样的东西呢？ 我认为意图更清楚，并且除非实际检测到 NA 值，否则也不会强制使用扩展 dtype，这有助于节省内存

方向略有不同，但像 nan_float_cast=True 这样的默认值呢？ 我认为意图更清楚，并且除非实际检测到 NA 值，否则也不会强制使用扩展 dtype，这有助于节省内存

这取决于选项的行为。 现在，我认为意图是对所有整数列使用例如可为空的整数 dtype，而不仅仅是那些具有缺失值的整数列，否则会被强制转换为浮点数。 （此外，对于布尔值，如果有浮点数，它们现在会被强制转换为对象）

确实，不对所有列都这样做可以节省内存，但我个人更喜欢对所有列都这样做：1）根据列的“逻辑”类型，而不是缺失值的存在，您会得到一致的结果（例如，如果只读取文件的一部分，这可能已经不同 2) 读取后也可以引入缺失值（例如重新索引、合并、..），然后具有可为空的整数 dtype 确保它不会被强制转换为然后浮动，即使原始数据没有 nans

这取决于选项的行为。 现在，我认为意图是对所有整数列使用例如可为空的整数 dtype，而不仅仅是那些具有缺失值的整数列，否则会被强制转换为浮点数。 （此外，对于布尔值，如果有浮点数，它们现在会被强制转换为对象）

是的，我同意 - 对该意图的澄清肯定会推动这一点。

我认为除非需要，否则不值得添加掩码 - 它肯定会对内存产生重大影响。 如果我的简单数学适用于 1000 万行 x 10 列
添加掩码的整数值块至少需要 100 MB 以上的内存

除非需要，否则我认为不值得添加面具

但是，与其使用此处讨论的选项来限制将转换为掩码/可为空 dtype 的列，不如尝试通过改进实现来解决此内存问题。 我们对此的具体想法：1）使掩码可选，因此它可以是没有丢失的数据（我认为这应该不会太难）2）使用位掩码而不是布尔数组掩码进行调查（这可能更难，因为在 Python 中没有标准实现，因此需要一些自定义代码）。

请注意，可为空的 dtypes 无论如何仍然是实验性的（有很多操作还不起作用，有些东西更慢，..），所以我认为这个选项将在初始阶段主要用于允许轻松进行实验， 试试看。 对于这样的用例，我认为转换所有可能的列而不是通过不转换所有列来解决内存问题更有用。

来自@WillAyd

• 如果我们将来添加更多的扩展类型，而不仅仅是专注于 NA 处理，那么我们必须在此之上添加另一个关键字来解析，这只会使事情变得更加复杂

我对此有另一个想法。 由于像Series.shift()这样的方法创建了包含 NA 的条目，我认为任何新的扩展类型 _always_ 都需要对 NA 做一些事情，恕我直言，我认为我们希望他们使用pd.NA而不是np.nan来表示“缺失值”

这可能意味着诸如use_missing_value_dtype类的关键字可能有意义，尽管要键入的内容很多。

如果我们真的想强调这完全是关于缺失值，那么使用pd.MV而不是pd.NA可能有助于理解这一点，但这可能会打开一整罐蠕虫。

@WillAyd关于掩码数组的内存问题： https : https://github.com/pandas-dev/pandas/issues /31293关于探索掩码的位数组。

诸如use_missing_value_dtype类的关键字可能有意义

由于 float dtype 中的 np.nan 也用作“缺失值”，我不确定这是否比use_nullable_dtype更模糊（鉴于反对use_nullable_dtype的论点，即还有其他 dtypes 也是“可为空”而不使用 pd.NA）。

as_NA_dtypes （支持 pd.NA）

这是非常明确的！
对我来说，这个的一个缺点是我个人发现将它用作一般术语来谈论这个时听起来不太好（如散文中的“NA dtypes”）。

另一种选择是convert_dtypes=True/False 。 我不认为从名称中可以很清楚它会做什么，但这就是我们最终在https://github.com/pandas-dev/pandas/pull/30929 中的方法名称

诸如use_missing_value_dtype类的关键字可能有意义

由于 float dtype 中的 np.nan 也用作“缺失值”，我不确定这是否比use_nullable_dtype更模糊（鉴于反对use_nullable_dtype的论点，即还有其他 dtypes 也是“可为空”而不使用 pd.NA）。

as_NA_dtypes （支持 pd.NA）

这是非常明确的！
对我来说，这个的一个缺点是我个人发现将它用作一般术语来谈论这个时听起来不太好（如散文中的“NA dtypes”）。

我们可以结合这两个想法，即as_missing_value_NA_dtypes ，并且您在散文文本中说“缺失值 NA dtypes”表示使用pd.NA表示缺失值的 dtypes

另一种选择是convert_dtypes=True/False 。 我不认为从名称中可以很清楚它会做什么，但这就是我们在 #30929 中最终得到的方法名称

作为上面的作者，我会在 I/O 上下文中投票_反对_那个，因为convert_dtypes也有inherit_objects行为，所以现在我们对convert_dtypes有不同的含义两种不同的语境。

并且您在散文文本中说“缺失值 NA dtypes”表示使用 pd.NA 表示缺失值的 dtypes

对我来说，如果这是大多数人都能接受的妥协，那很好。 在这种情况下，我们应该将有关“可空整数数据类型”的文档部分更新为“具有 NA 缺失值的整数数据类型”或 .. （尽管标题有点长）

但就我个人而言，我只是建议：让我们在 pandas 文档/ dtypes in pandas 的上下文中将“可空”定义为“使用 NA 的

在上面的评论（https://github.com/pandas-dev/pandas/issues/29752#issuecomment-579112054）中是否有更多关于我的建议的反馈，以在熊猫文档的上下文中使用“可为空的dtype”作为含义“使用 NA 作为缺失值指示符的 dtype”？

抄送@pandas-dev/pandas-core

有道理，但可能会导致与 isnull 混淆，后者认为 np.NaN、pd.NaT、None 等为空。

isnull 认为 np.NaN、pd.NaT、None 等为空。

我们有一个isna函数，除了 NA 之外，它还将所有这些都考虑在内......所以是的，考虑到所有历史包袱，没有一个术语是理想的。
我们可以更新isnull的文档字符串以清楚地表明它是isna的确切别名，并且不会处理任何不同的“可为空数据类型”。

在这里友好ping。 如果我没有听到反对意见，我会认为可以使用术语“可为空的 dtypes”作为“使用 NA 作为缺失值指示符的 dtype”（在文档、文档字符串中，可能是关键字外部参照 #31242）

nullable_dtypes 不是很好

会考虑： return_dtypes='classic' 或 'modern'

这个关键字的重点是默认为 'modern' 吗？ 这只是为了兼容性？
否则我们将不得不弃用它来改变这似乎很麻烦

这个关键字的重点是默认为 'modern' 吗？ 这只是为了兼容性？
否则我们将不得不弃用它来改变这似乎很麻烦

最初的一点是它使人们更容易选择尝试新的 dtypes（类似于convert_dtypes方法，但作为读者的一个选项，因为这可以避免额外的转换）。
所以不，最初这个关键字不会默认使用可空/现代 dtypes（同样，因为我们不打算将可空整数 dtype 设为 pandas 1.x 中的默认 int dtype）

我不一定反对“现代”一词，但我个人认为它的描述性较差/更模棱两可（或主观）为“可空”。
例如，我们的分类 dtype 是“现代”dtype 吗？

我不一定反对“现代”一词，但我个人认为它的描述性较差/更模棱两可（或主观）为“可空”。

我同意乔里斯的看法。 经典/现代也意味着如果我们明年有更好的想法，我们必须使用“后现代”

我不一定反对“现代”一词，但我个人认为它的描述性较差/更模棱两可（或主观）为“可空”。

我同意乔里斯的看法。 经典/现代也意味着如果我们明年有更好的想法，我们必须使用“后现代”

我同意使用“现代”在未来会产生问题，即使我们没有更好的主意。 因为让我们说从现在起 5 年后事情仍然相同。 那么“现代”是5岁。 听起来很奇怪。

这里有两个问题在起作用：

1. 在写散文来描述支持pd.NA类型时使用什么措辞
2. 什么用作参数关键字

@jorisvandenbossche提出的建议是通过

1. “nullable dtype”表示“支持pd.NA Pandas dtype”
2. 使用关键字参数use_nullable_dtypes

这是另一种可能性：

1. “熊猫数据类型支持pd.NA ”
2. 关键字use_pd_NA_dtypes

我对以上任何一个都很好，只是想刺激讨论。

+1 用于将“nullabe”定义为“使用 NA 作为缺失值指示符的 dtypes”。

由于我们已经在“可空整数”或“可空布尔值”dtypes 中使用了“nullable”，并且我想我们希望在该上下文中继续使用该术语，因此我更喜欢“nullable”而不是“dtypes support pd.NA ” .
这两个当然是不模棱两可的情况，因为它们以前无法存储 NA/NaN，而在将来我们可能会有更多模棱两可的情况，例如浮点数。 但是如果我们使用“nullable”，我们可以对所有支持 NA 的 dtype 一致地使用它，而不仅仅是以前不支持 NaN 的那些。

现在，当然，即使我们决定使用“nullable”作为术语，我们仍然会在 docs/docstrings 的很多地方重复添加短语“dtypes support pd.NA ”，正是为了建立这种关系.

我仍然不是nullable_dtypes的粉丝。 我们真的需要在这里通过相同的关键字同时处理 StringArray 和 IntegerArray 吗？ 我想知道将它们分开是否会使事情变得更清楚

对于前者，我想知道我们是否应该这样做，即关键字不会切换行为。 以前来自 IO 例程的对象 dtype 在某个点被替换为字符串 dtype

似乎比整数的侵入性小 -> 浮点数变化，这可能确实值得一个专用的关键字

我想知道我们是否应该这样做 [关于返回字符串 dtype 而不是对象 dtype]

"string" dtype 不向后兼容 object dtype，所以这就是现在（除了它是实验性的）的原因，这不是默认值。 不过，我们确实希望在某个时候改变这一点。 但我认为这值得专门讨论。

我想知道将它们分开是否会使事情变得更清楚

这不仅仅是 IntegerArray 与 StringArray。 目前，它也已经是 BooleanArray （所以只有 int 的关键字不会涵盖这一点）。 并且在未来，我希望添加其他 dtype，例如带有 NAs 的 float dtype (https://github.com/pandas-dev/pandas/issues/32265)，...
所以是的，对于可为空的整数，我们可以添加一个特定的关键字，但对我来说，它是关于启用所有使用 NA 的新 dtypes，并不断为每个新关键字添加新关键字似乎不可持续？

是全局配置选项的替代方案，并且完全避免添加关键字。

如果用户只想将新类型用于单个 IO 读取调用，则可以使用with pd.option_context(...):语法（或pd.read_excel('filename.excel').as_nullable_types() ）。

潜在的选项命名可能是use_pandas_2.0_api 、 use_experimental_dtypes 、 use_StringDType排序的层次结构。 其中use_experimental_dtypes包括use_StringDType和use_pandas_2.0_api包括use_experimental_dtypes

我们现在将开始实施预期的 pandas 2.0 行为。 （这些选项将在 2.0rc 中删除）

如果没有关键字添加，我们也可以开始添加它来表示 DataFrame 构造函数，而无需更改 api。

是全局配置选项的替代方案，并且完全避免添加关键字。

全局配置当然很有趣，并且不时建议将某些内容作为选择加入新 dtypes 的一种方式/另一种尝试的方式。
就个人而言，我认为将其作为关键字（“本地”选项）也很有意义，因为配置选项在全局范围内有效（例如还会影响您正在使用的所有库），并且根据您的情况，其中一个可能更好地工作。

无论如何，对于全局配置选项，我们需要就名称达成一致；)（理想情况下是一致的）

或 pd.read_excel('filename.excel').as_nullable_types()

这样的as_nullable_types()已经存在了，它就是convert_dtypes() （原来是先叫as_nullable_dtypes ，后来改名妥协了）。
除了这种方法之外，还有一个关键字的原因是避免双重转换（例如，首先将整数转换为读取器中的浮点数，然后推断浮点数并将其转换回convert_dtypes整数）。

我们也可以开始添加这个来表示 DataFrame 构造函数，

我认为添加这样的关键字确实也是一个好地方。

在任何命名中使用“pandas 2.0”的潜在问题是，现在不能保证这实际上是pandas 2.0中的默认值..（这将取决于pandas 2.0何时发生，我们在改进方面取得了多大进展可为空的 dtypes 等）

除了这种方法之外，还有一个关键字的原因是避免双重转换（例如，首先将整数转换为读取器中的浮点数，然后推断浮点数并将其转换回convert_dtypes整数）。

另一个原因是让“可为空的 dtypes”在不同的读者中工作可能会在不同的时间为不同的读者实现。 例如，也许read_csv()首先完成，然后让它在read_excel() ， read_sql()稍后发生。 因此，并非所有读者都存在关键字参数。 如果我记得当我试图弄清楚这一点时，必须为每个读者单独检测可空数据类型的使用，但我可能错了。

试图在这里达成共识或妥协的另一种尝试。

因此，对于术语+关键字或选项的命名方案，主要建议是：

• 术语：“nullable dtype”的意思是“支持 pd.NA 的 Pandas dtype”
• 关键字/选项名称： use_nullable_dtypes=True/False
  
  
  
  • 这是明确的，它导致使用pd.NA作为缺失值指示符的可为空的dtypes。
  
  

滚动线程，提到了以下关键字名称的替代方案：

• use_extension_dtypes
  
  
  
  • 问题在于该关键字通常不适用于“扩展”数据类型，而仅适用于使用pd.NA作为缺失值指示符（可为
  
  
• use_modern_dtypes=True/False或return_dtypes=‘classic’/‘modern’
  
  
  
  • “现代”不是很具有描述性，而且还依赖于时间（几年后其他东西可能是最新的“现代”方式）
  
  
• na_float_cast
  
  
  
  • 仅关于整数未转换为浮点数，因此不是所有可为空的 dtypes 的通用名称
  
  
• use_pandas_2.0_api
  
  
  
  • 这取决于那些 dtypes 实际上成为 pandas 2.0 中的默认值，这是我们目前还不能保证的
  
  
• use_missing_value_dtype
  
  
  
  • pd.NA不是我们唯一的“缺失值”，np.nan（对于 float64）和 pd.NaT 仍然是缺失值。 所以 IMO 这并不像use_nullable_dtype那样模棱两可
  
  
• use_experimental_dtypes
  
  
  
  • 这对我来说是一个可行的选择，但 IMO 在它的作用上也不太清楚/描述性
  
  
• use_NA_dtypes （或use.pd_NA_dtypes或use_missing_value_NA_dtypes ）
  
  
  
  • 这可以与文档中的“pandas dtypes support pd.NA”一起使用。
  
  

我认为只有最后两个要点是可行的替代方案。 对我来说，如果大多数人都能接受，那两者中的一个就可以了。 但我也认为“可为空的 dtypes”更好：在讨论可为空的整数和布尔 dtypes 时，我们已经在文档中使用了这个术语（并且我们之前没有使用“可为空的”来表示其他任何东西）。

我知道术语“可空”并不完美（例如，我们当前的（基于 numpy 的）浮点列是否使用 NaN 作为缺失值指示符“可空”？），但我们仍然需要一些术语来指代那些使用pd.NA作为缺失值指标，到目前为止，我认为“可空”仍然是我们拥有的最好的。

@jorisvandenbossche很棒的总结。 我喜欢use_nullable_dtypes和use_NA_dtypes （注意：在你上面帖子的开头，你用单数和use_nullable_dtype而不是复数use_nullable_dtypes ，所以我们还必须弄清楚我们是想要单数还是复数）。

我想知道我们是否应该创建一个民意调查并让人们投票。 正如我在电话会议上所说的那样，如果您不喜欢迄今为止提出的任何建议，您必须提出其他建议以添加到列表中，而不仅仅是说“我不喜欢其中任何一个”：- )

您在 use_nullable_dtype 中使用了单数，而不是在 use_nullable_dtypes 中使用了复数，因此我们还必须弄清楚我们是想要单数还是复数）。

啊，那是一种类型（现在已编辑）。 由于有多个可为空的 dtype，我认为我们应该只使用复数。

+1 用于“可为空数据类型”的定义和关键字use_nullable_dtypes 。

我更喜欢 use_na_dtypes 来明确

从我的iPhone发送

2020 年 5 月 15 日上午 9:39，Tom Augspurger通知@github.com 写道：

+1 用于“可为空 dtypes”的定义和关键字 use_nullable_dtypes。

—
你收到这个是因为你被提到了。
直接回复此邮件，在 GitHub 上查看，或取消订阅。

@WillAyd这是否也意味着您更愿意将我们文档中“可为空的 dtypes”的所有用法替换为“使用 NA 作为缺失值的 dtypes”或“支持 pd.NA 的 dtypes”等？ （例如在 https://pandas.pydata.org/docs/user_guide/boolean.html）

另一个友好的ping ..

@WillAyd您的偏好有多强？ 可能有点难以准确回答，但意思是：我仍然偏爱use_nullable_dtypes ，并且由于大多数参与的声音都同意，我仍然想选择use_nullable_dtypes如果您的偏好不是太强。
（而且由于我是推动它的人，所以我做出最终决定有点困难......）

实际上，对于关键字本身，我对use_NA_dtypes也比较满意。 但是对于在文档等中运行文本，我更愿意谈论“可为空的 dtypes”（实际上我们现在已经这样做了）。 如果我们在文档中这样做，我认为我们也应该与关键字保持一致。

我仍然认为，一旦我们添加了 floatNA 类型， use_NA_dtypes就更好了。 不过我不会在意这点

@jreback对此也持不同意见，所以应该看看他的立场并从那里开始

@WillAyd在这种情况下，你能回答我关于你将如何处理文档的问题吗？

当然，我认为将它们称为 NA dtypes 比 Nullable dtypes 更清楚

已经来到这里， use_nullable_dtypes与我们当前的文档描述相匹配。

我们认为这是 1.1 的阻碍吗？ 如果是这样，有人愿意为此工作吗？

我想我们合并当前的提案

任何人（@Dr-Irv、@jorisvandenbossche）都能够解决这个问题？ 如果只需要几天时间，这对于 1.1 来说似乎是值得的。

@TomAugspurger对我来说，不会花几天的时间，因为我认为应该在读者中进行非常低的更改，我必须弄清楚该代码是如何工作的。 简单的解决方案是在当前读取操作之后在各种读取器中使用convert_dtypes ，但从内存的角度来看，这将是低效的。

我是从问题 #35576 被送到这里的。 （虽然 https://github.com/pandas-dev/pandas/issues/29752#issuecomment-613077209 可能暗示这确实需要单独讨论？）

就我个人而言，在即将推出的“Modern Pandas”版本中，我最关心的“关闭”是回退到对象 dtype。 （因为它使事情的速度慢了几个数量级，而且它很容易在幕后“为你”发生）。 是的，其中一些是由于需要pd.NA用于不支持它的 numpy dtype 造成的，但并非所有情况都来自于此。

作为一个非常具体的用例，我想要一种让read_csv()始终使用 StringDtype 而不是对象 dtype 的方法。 （这会大大简化我的生活。）但我不清楚“可为空的 dtypes”指定是否适用于此。 在我看来，对象 dtype 肯定可以为空，不是吗？ 所以，我个人不会认为use_nullable_dtypes=True影响这一点。 想法？

@chrish42看看这个评论： https :

“可空数据类型”的定义是“支持 pd.NA 的 Pandas 数据类型”。 这包括StringDtype但不包括object ，因此一旦实施，您将能够获得StringDtype作为pd.read_csv()

@Dr-Irv Cool，谢谢。 这对我来说并不是很清楚。 至少，不像其他时候，对象没有理由不支持pd.NA ，对吧？ 对我来说， use_nullable_types名称的主要缺点是，即使是不需要可空类型的人也会从将其设置为 True 中受益。 （嗯，几乎每个人都会从将它设置为 True 中受益。）但我想这里没有完美的名称，并且好的文档必须完成其余的工作并向用户传达名称没有传达的内容。

无论如何，真的很期待自动转换为对象（因为字符串）和浮动（因为 NA）的那一天成为过去。 所以谢谢大家！

object 没有理由不支持 pd.NA，对吧？

我建议反对。 需要编写算法来明确处理 NA，因为它太不寻常了。

object 没有理由不支持 pd.NA，对吧？

我建议反对。 需要编写算法来明确处理 NA，因为它太不寻常了。

有关专用问题，请参阅 #32931

@chrish42如果您只对获得新的string dtype（以避免对象 dtype）感兴趣，那么use_nullable_dtypes=True确实不是很明显（我认为这也是原因之一）对于上面的长时间讨论）。

但是，我们当然想要一个关键字来选择所有可为空的 dtypes，所以例如也可以为 nullable int 和 nullable bool 以避免强制转换为 float 等。然后这个名字更有意义。 添加另一个关键字来获取string dtype 可能太多了。