numpy int64数组追加空列表时dtype转为float64是否为预期行为？

现象复现 #

dtype为int64的整数类型numpy数组调用np.append追加整数值时，待追加列表非空则返回结果保持int64类型；待追加列表为空时，返回数组dtype会变为float64，复现代码：

import numpy as np

a = np.arange(10, dtype='int64')

np.append(a, [10])  # 返回dtype为int64的数组
# array([ 0,  1,  2,  3,  4,  5,  6,  7,  8,  9, 10])

np.append(a, [])    # 返回dtype为float64的数组
# array([0., 1., 2., 3., 4., 5., 6., 7., 8., 9.])

复现环境：Numpy 1.22.4，Python 3.8.0

行为定性 #

该现象属于numpy的预期设计行为，不属于bug。

背后逻辑 #

• np.append没有独立的拼接实现，底层完全基于np.concatenate封装：执行时会先把传入的原数组、待追加值都转换为numpy数组，再沿指定轴做拼接。
• numpy对无显式dtype的空Python列表做转换时，默认生成dtype为float64的空数组，可直接验证：执行np.array([])返回的空数组dtype就是float64，这是numpy长期沿用的默认类型规则。
• 数组拼接时numpy会执行类型提升逻辑，自动选择两个输入数组都能兼容的公共dtype：原数组是int64，待拼接的空数组是float64，int64可安全隐式转换为float64，因此最终拼接结果的dtype被提升为float64——哪怕待拼接的空数组里没有任何实际元素，类型提升流程也会正常执行。

关于文档预期的说明 #

np.append的实现没有为「待追加值为空」的场景设计特殊分支，所有输入走统一的转换、拼接流程，不会因为没有实际追加内容就跳过类型推断、类型提升步骤，直接返回原数组同类型副本。这种设计的初衷是保持不同输入下函数执行路径的一致性，避免特殊分支带来的行为不一致，但确实和部分用户的直觉预期存在偏差。

规避方案 #

如果需要保证空输入下返回数组类型和原数组一致，可以选择以下两种处理方式：

• 待追加值为空时，手动生成原数组的副本，跳过np.append调用
• 传入待追加值时显式指定dtype和原数组一致，例如写为np.append(a, np.array([], dtype=a.dtype))

内容的提问来源于stack exchange，提问作者asdf