Skip to content

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

Description

@joaquinhuigomez

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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions