You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Type stubs omit the connection keyword on module-level read_json and write_csv #627
The module-level duckdb.read_json(...) and duckdb.write_csv(...) accept a connection= keyword at runtime, but _duckdb-stubs/__init__.pyi doesn't declare it for either, so every type-checked call that passes connection= is reported as an error (pyright: No parameter named "connection"). The neighbouring read_parquet stub does declare it, and the C++ registration for both functions ends with nb::arg("connection").none() = nb::none() (src/duckdb_python.cpp, the read_json and write_csv definitions), so this is a stub gap rather than a runtime one — the same shape as #386.
To Reproduce
import duckdb, tempfile, os, json
con = duckdb.connect()
d = tempfile.mkdtemp()
p = os.path.join(d, "x.json")
with open(p, "w") as f:
f.write(json.dumps([{"a": 1}, {"a": 2}]))
print(duckdb.read_json(p, connection=con).fetchall()) # runtime OK
duckdb.write_csv(duckdb.values([1]), os.path.join(d, "o.csv"), connection=con) # runtime OK
[(1,), (2,)]
Type-checking the same script:
pyright x.py
error: No parameter named "connection" (reportCallIssue) # read_json
error: No parameter named "connection" (reportCallIssue) # write_csv
A diff of every nb::arg(...) registration in src/**/*.cpp against the stub signatures shows exactly these two functions as gaps. tests/fast/test_non_default_conn.py already asserts connection=duckdb_cursor on ten module functions and covers neither of these.
OS:
macOS 15 (aarch64)
DuckDB Package Version:
1.5.5 (also present on main)
Python Version:
3.13
Full Name:
Joaquin Hui Gomez
Affiliation:
Independent contributor
What is the latest build you tested with? If possible, we recommend testing with the latest nightly build.
I have tested with a source build
Did you include all relevant data sets for reproducing the issue?
Yes
Did you include all code required to reproduce the issue?
Yes, I have
Did you include all relevant configuration (e.g., CPU architecture, Python version, Linux distribution) to reproduce the issue?
Yes, I have
Happy to send the two-line stub fix plus the two test cases in test_non_default_conn.py if that's welcome.
Thanks for the precise report. I rechecked it on 2.0.0. The module level read_json and write_csv are now Python functions, read_json declares connection= directly, and mypy accepts both calls from your repro with no errors. The runtime behavior is unchanged: the relation binds to the connection you pass. I am closing this as fixed in 2.0.0. If you still see the error with 2.0.0 installed, please reopen with the checker and its version.
Activity
tojacob03 commentedon Sep 29, 2026
I'd like to take this one. The fix only touches the stubs; PR coming shortly.
evertlammerts commentedon Oct 27, 2026
Thanks for the precise report. I rechecked it on 2.0.0. The module level read_json and write_csv are now Python functions, read_json declares connection= directly, and mypy accepts both calls from your repro with no errors. The runtime behavior is unchanged: the relation binds to the connection you pass. I am closing this as fixed in 2.0.0. If you still see the error with 2.0.0 installed, please reopen with the checker and its version.