wave.Wave_write.setparams() rejects valid PCM-to-IEEE-float parameter changes
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
The issue identifies Lib/wave.py, specifically Wave_write.setparams(), setformat(), and setsampwidth(). Read those methods and the tests for IEEE float support, then reproduce the PCM-to-float reconfiguration case from the report. Done means valid 4-byte and 8-byte float parameters can be set before any frames are written, including after PCM widths of 1, 2, or 3 bytes.
由索引模型根据 Issue 内容生成。
描述
Bug report
Bug description
wave.Wave_write.setparams() rejects valid IEEE-float parameters when the writer was previously configured with a PCM sample width of 1, 2, or 3 bytes, even though no audio frames have been written.
The same parameters succeed on a fresh writer.
Reproducer
import io
import wave
float_params = (
1, 4, 8000, 0, "NONE", "not compressed",
wave.WAVE_FORMAT_IEEE_FLOAT,
)
with wave.open(io.BytesIO(), "wb") as writer:
writer.setparams(float_params)
print("Fresh writer: OK")
with wave.open(io.BytesIO(), "wb") as writer:
writer.setparams((1, 2, 8000, 0, "NONE", "not compressed"))
writer.setparams(float_params)
print("Reconfigured writer: OK")
Actual behavior
The fresh-writer configuration succeeds. Reconfiguring the PCM writer raises:
wave.Error: unsupported sample width for IEEE float format
Expected behavior
Both configurations should succeed. The new sample width is 4 bytes, which is supported for IEEE float, and no frames have been written.
Implementation details
Wave_write.setparams() calls setformat(format) before
setsampwidth(sampwidth).
However, setformat() validates the existing self._sampwidth against the
new format. This rejects the previous 2-byte PCM width before the valid
new 4-byte width can be installed.
The same failure occurs when switching from PCM widths of 1, 2, or 3 bytes
to either 4-byte or 8-byte IEEE float. Switching from 4-byte PCM succeeds.
Related: #60729 added IEEE-float support.
CPython versions tested on
Python 3.16.0a1+dev, debug build based on commit 8b7d6c53eee.
Also reproduced using Lib/wave.py from upstream commit
f5bd07700ecd0f02cc424666b871f51de03b9232, executed under Python 3.14.8.
This additional check was not a full build of that upstream commit.
Operating systems tested on
macOS
Output from running python -VV
Python 3.16.0a1+dev (heads/gh-159868-userstring-affixes-dirty:8b7d6c53eee, Oct 20 2026, 15:46:41) [Clang 21.0.0 (clang-2100.3.34.2)]
CPython versions tested on:
3.16
Operating systems tested on:
macOS
Linked PRs
- gh-160031
- 主要语言
- Python
- 星标
- 77.8k
- 派生
- 37.7k
- 平均合并
- 12 小时 14 分钟
- 30 天内合并 PR
- 729
环境准备
在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
python/cpython 的其他 Issue
-
tests topic-profiling type-bug
难度 2/5 1-3 小时 新手友好度 76/100
python/cpython#160881 · 1 条评论 ·
维护者通常 1 天内回复
-
3.16 build pending type-bug
难度 2/5 1-3 小时 新手友好度 62/100
python/cpython#160829 · 5 条评论 ·
维护者通常 1 天内回复
-
dependencies infra topic-ensurepip
难度 2/5 1-3 小时 新手友好度 66/100
维护者通常 1 天内回复
-
symtable: repr() of a Symbol raises TypeError under -X lazy_imports=all可能已有人在做 @anistark 于 1 天前认领。 未关闭stdlib topic-lazy-imports type-bug
难度 2/5 1-3 小时 新手友好度 72/100
python/cpython#160810 · 4 条评论 ·
维护者通常 1 天内回复
-
tarfile: extractfile(member).read() of a sparse member is slow due to repeated bytes concatenation可能已有人在做 @devdavidejesus 今天认领。 未关闭performance stdlib triaged type-bug
难度 2/5 1-3 小时 新手友好度 75/100
python/cpython#160774 · 2 条评论 · 已指派 1 人 ·
维护者通常 1 天内回复
相似的 Issue
-
Support .aac audio uploads可能已有人在做 @julien731 今天认领。 未关闭feature
难度 2/5 1-3 小时 新手友好度 78/100
nimblehq/audio-transcriber#153 ·
-
help wanted
难度 2/5 1-3 小时 新手友好度 68/100
antonyrag/ragleap-core#1062 ·
-
needs-triage
难度 2/5 1-3 小时 新手友好度 76/100
gke-labs/kube-agents#4321 ·
维护者通常 1 天内回复
-
enhancement help wanted
难度 2/5 1-3 小时 新手友好度 76/100
Git-Hospital/githealthcheck#61 ·
维护者通常 1 天内回复
-
changelog investigate
难度 2/5 1-3 小时 新手友好度 67/100
ramnes/notion-sdk-py#433 ·