What happens?
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
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?
Did you include all relevant configuration (e.g., CPU architecture, Python version, Linux distribution) to reproduce the issue?
Happy to send the two-line stub fix plus the two test cases in test_non_default_conn.py if that's welcome.
What happens?
The module-level
duckdb.read_json(...)andduckdb.write_csv(...)accept aconnection=keyword at runtime, but_duckdb-stubs/__init__.pyidoesn't declare it for either, so every type-checked call that passesconnection=is reported as an error (pyright:No parameter named "connection"). The neighbouringread_parquetstub does declare it, and the C++ registration for both functions ends withnb::arg("connection").none() = nb::none()(src/duckdb_python.cpp, theread_jsonandwrite_csvdefinitions), so this is a stub gap rather than a runtime one — the same shape as #386.To Reproduce
Type-checking the same script:
A diff of every
nb::arg(...)registration insrc/**/*.cppagainst the stub signatures shows exactly these two functions as gaps.tests/fast/test_non_default_conn.pyalready assertsconnection=duckdb_cursoron 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?
Did you include all relevant configuration (e.g., CPU architecture, Python version, Linux distribution) to reproduce the issue?
Happy to send the two-line stub fix plus the two test cases in
test_non_default_conn.pyif that's welcome.