Type stubs omit the `connection` keyword on module-level `read_json` and `write_csv`

Start in _duckdb-stubs/init.pyi by comparing the module-level read_json and write_csv signatures with read_parquet, then check the corresponding registrations in src/duckdb_python.cpp. Add coverage for connection= in tests/fast/test_non_default_conn.py and run those tests plus pyright on the reproduction script; done means both calls type-check and the tests pass.

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

[(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.