`Path.read_text()` accepts no arguments, while `open(encoding=...)` works
Author: ggozadCreated Sep 18, 2026Updated Sep 18, 2026
pathlib.Path.read_text() rejects both keyword and positional arguments on pydantic-monty==0.0.23, though the equivalent open() call accepts encoding.
Reproduction
from pydantic_monty import CallbackFile, Monty, OSAccess
vfs = OSAccess([CallbackFile("/data/a.txt", lambda _p: "hello", lambda _p, _c: None)])
with Monty() as mt, mt.checkout() as s:
s.feed_run(
"from pathlib import Path\nprint(Path('/data/a.txt').read_text(encoding='utf-8'))",
os=vfs,
)| call | 0.0.23 |
|---|---|
Path("/data/a.txt").read_text() |
works |
Path("/data/a.txt").read_text(encoding="utf-8") |
TypeError: read_text() takes no keyword arguments |
Path("/data/a.txt").read_text("utf-8") |
TypeError: read_text() takes no arguments (1 given) |
open("/data/a.txt", encoding="utf-8").read() |
works |
CPython's signature is read_text(encoding=None, errors=None, newline=None).
For context, in haiku.rag, measured over evaluation runs, out of 47,670 sandbox executions about 2,956 failed on a code error and 460 of those were this TypeError, second only to #490.
Model-written code carries encoding="utf-8" on read_text as a habit, and the working open() form makes the failure look arbitrary.
#739 covers the write side of the same asymmetry, Path.write_text(encoding=...), so these may be one fix.
Environment
pydantic-monty==0.0.23- Python 3.13, macOS arm64
Source: pydantic/monty