Python 3.15 推导式解包怎么读：星号展开、字典合并与变量边界

Python 3.15 把 PEP 798 的推导式解包带进了语言语法：列表、集合、字典推导式以及生成器表达式，都可以在最外层使用 * 或 **。它解决的是“每轮循环得到一组值，还要把这组值合并进结果”的问题；但它不会改变字典覆盖规则，也不会把推导式变量泄漏到外层。

记住一个判断：普通表达式对应 append/add/单个键赋值，星号表达式对应 extend/update；先写出等价循环，再决定新语法是否值得采用。

步骤一：先把星号位置看成每轮展开

旧代码通常这样展平多组列表：

flat = []
for part in parts:
    flat.extend(part)

在 Python 3.15 中，等价写法是 flat = [*part for part in parts]。星号不是“把列表包进结果”，而是告诉推导式把当前 part 的成员逐个并入外层列表。PEP 798 只允许它出现在表达式的最外层，所以 [value * 2 for value in parts] 与 [*value * 2 for value in parts] 不是可以随意互换的两种写法。

步骤二：列表、集合与字典分别对应什么结果

三种容器的语义可以用一张小表记住。这里的集合推导式负责去重，字典推导式负责按顺序更新，最终都形成一个可检查的合并结果：

例如 records = [{"mode": "safe"}, {"mode": "fast", "retry": 2}] 时，{**record for record in records} 的结果是 {"mode": "fast", "retry": 2}。这不是深度合并：嵌套字典仍会整体替换。若业务需要字段级深合并，仍应显式写策略或调用专用库。

步骤三：生成器与变量作用域怎么判断

(*part for part in parts) 产生的是一个生成器。它相当于外层循环配合内层 yield，调用 list(generator) 时才逐个取得 part 的成员，因此适合不想立刻构造完整列表的场景。它并不会把每个 part 原样吐出。

PEP 798 也明确不改作用域规则。普通推导式的循环变量不会在外层留下新绑定；但赋值表达式本来就会绑定到包含它的作用域。例如 g = (*(last := [i, i + 1]) for i in (0, 2))，创建 g 时不要求 last 已存在，第一次调用 next()（这里实际写作 next(g)）后，last 这个外层变量才会变成 [0, 1]，再次推进才更新为 [2, 3]。这里变化的是求值时机，不是星号改变了作用域。

步骤四：把旧循环改成可验证的小工具

如果项目已经确定运行在 Python 3.15，可以把配置片段合并写成：

def merge_config(records):
    return {**record for record in records}

records = [{"timeout": 2}, {"timeout": 5, "retries": 1}]
assert merge_config(records) == {"timeout": 5, "retries": 1}

落地时先确认解释器版本，再确认调用方是否接受“后者覆盖前者”。需要兼容 Python 3.14 或更早版本时，继续使用 merged = {}; for record in records: merged.update(record) 更稳妥；不要为了少一行代码牺牲部署边界。列表和集合同理：先用固定输入检查顺序与去重，再替换生产路径。

常见问题：哪些写法仍然不成立

可以用 ** 写列表推导式吗？

不可以。字典解包只能进入字典推导式；列表和生成器使用 *，集合使用 *。

字典推导式解包会递归合并吗？

不会。它与连续 update 的浅层覆盖一致，嵌套对象不会自动递归。

新语法会让旧版本代码自动兼容吗？

不会。包含 PEP 798 语法的文件在旧解释器上无法解析，跨版本发布要保留旧写法或把新语法隔离在明确的运行时边界内。