add python 3.15 support

[abraaoz]

Adds CPython 3.15 to the supported versions. Unlike the 3.14 PR (#159), the CI matrix alone is not enough: pyo3 0.25.1 refuses the interpreter outright (the configured Python interpreter version (3.15) is newer than), and PYO3_USE_ABI3_FORWARD_COMPATIBILITY=1 does not help, it gets past the version check and then fails to compile (the trait bound PyTime: PyTypeInfo is not satisfied, 4 errors). So this bumps pyo3 0.25.1 -> 0.29 and migrates the code with it.

Migrations applied, all from PyO3's own migration guide

change	sites
Python::with_gil -> Python::attach	30
.downcast*() -> .cast*()	6
GILOnceCell -> PyOnceLock	2
FromPyObject<'py> -> FromPyObject<'_, 'py> with type Error and extract(Borrowed<..>)	3 impls
pyo3::PyObject -> Py<PyAny> (alias deprecated)	3 files
conversion::FromPyObjectBound -> FromPyObject	1
TaskLocals::clone_ref -> clone	1

Two that are not renames:

• rustdriver_future's T gains Send + 'static, which pyo3_async_runtimes::tokio::future_into_py now requires.
• extract::<T>() on a #[pyclass] returns PyClassGuardError, which RustPSQLDriverError cannot absorb. Converted via PyErr at the two macro sites, since RustPSQLDriverError::RustPyError already carries #[from] pyo3::PyErr.

Verified

Built and installed against CPython 3.15.0 (final) on macOS arm64, then ran the whole suite against PostgreSQL 18 with TLS on: 274 passed, 0 failed, test_ssl_mode.py and test_binary_copy.py included (pyarrow 26.0.0 ships cp315 wheels, and pgpq is abi3).

Your prek hooks pass locally on Rust 1.98.0 and 1.99.0, read from their exit codes: cargo fmt --check with your config, cargo clippy -p psqlpy -- -W clippy::all -W clippy::pedantic -D warnings (and the CI job's --all-features variant), and cargo check, all 0. Clippy 1.99 needs pyo3 0.29.3, which fixes clone_on_copy lints its #[pyclass] macros emitted on Copy types.

One lint that is new, not broken

Clippy 1.98 adds clippy::unused_async_trait_impl, split out of unused_async, and pyo3 0.29 expands async #[pymethods] as trait impls, so it fires on four functions that already carry #[allow(clippy::unused_async)]. The new name was added beside the old one rather than restructuring those functions into impl Future, since the async there is your choice about the Python-facing API.

One unrelated line

src/statement/query.rs:53 had format!("${}", &counter), which current clippy rejects as a redundant reference. It is not part of this migration and I did not otherwise touch that file, but the hook lints the whole crate, so the branch cannot go green without it. Dropped to format!("${counter}").

Two things for you to decide

pyo3-async-runtimes now points at the released crate (0.29) instead of your fork's psqlpy branch. The fork is pinned to the old pyo3 line and does not build against 0.29; upstream has since published 0.29.0. I do not know what your fork carries that upstream does not, so if that branch holds a patch you need, this dependency line should be rebased instead of replaced. That is your call, not mine.

All 20 #[pyclass] types opted IN to the FromPyObject derive. PyO3 0.29 makes that derive opt-in for #[pyclass] types implementing Clone, and prek runs clippy with -D warnings, so the deprecation is a hard failure rather than a note. Every one of them got from_py_object, which keeps today's behaviour exactly; skip_from_py_object would have removed those conversions from your public API, which is not a migration PR's call to make.

[chandr-andr]

@abraaoz Hello! Thanks for python3.15 support. I approved the checks, let's see it everything is ok

[abraaoz]

Thanks for approving the run! The 27 red boxes are one real failure and 26 cancellations from fail-fast: only ubuntu-latest-3.15-17 actually failed, at actions/setup-python, with The version '3.15' with architecture 'x64' was not found for Ubuntu 24.04. Every 3.15 entry in actions/python-versions is still a prerelease (newest is 3.15.0-rc.2), and setup-python resolves only stable versions unless allow-prereleases is set.

I pushed that one line to the test workflow and to the four setup-python steps in release.yml, which would hit the same wall at publish time.

Could you approve the run again so we see how far the build gets on 3.15?

[abraaoz]

Python 3.15.0 is out, so I moved the branch from the release candidate to the final release:

• allow-prereleases is gone from test.yaml and release.yml: setup-python now resolves 3.15 to 3.15.0.
• The py315 tox env is gone, and with it the skip of test_binary_copy.py: pyarrow 26.0.0 ships cp315 wheels and pgpq is abi3, so 3.15 runs the full suite through the default [testenv].
• pyo3 0.29.2 -> 0.29.3, lock only. Clippy 1.99, now stable, flags clone_on_copy inside the code #[pyclass(from_py_object)] expands to on the nine Copy enums; 0.29.3 fixes those macro lints.

Verified locally on CPython 3.15.0 (macOS arm64) against PostgreSQL 18 with TLS on: 274 passed, 0 failed, test_ssl_mode.py and test_binary_copy.py included. The prek hooks (fmt, clippy pedantic with -D warnings, check) and the CI's clippy with --all-features pass on Rust 1.98.0 and 1.99.0.

The run on my previous push never started (0 jobs), so could you approve the workflows once more?

Side note: main's Rust code currently fails the Prek clippy hook on stable (see the pre-commit-ci update runs) with the unused_async_trait_impl and redundant-reference lints this PR already fixes. And #173 also replaces the pyo3-async-runtimes fork with the crates.io release, so both PRs agree on that dependency.

[chandr-andr]

@abraaoz Hello! Thanks for the fixes, I approved the run, let's check.
Wanna release it as soon as possible