trim

Author: evertlammerts

src/include/duckdb_python/nb/conversions/enum_string_caster.hpp

@@ -39,7 +39,7 @@
 					value = FromIntegerFn(nanobind::cast<int64_t>(src));                                               \
 					return true;                                                                                       \
 				}                                                                                                      \
-				/* Registered nb::enum_ instances aren't int subclasses (unlike pybind11's), so accept a member  */    \
+				/* Registered nb::enum_ instances aren't int subclasses, so accept a member  */                        \
 				/* of the registered enum by reading its integer .value.                                         */    \
 				nanobind::handle enum_type = nanobind::type<EnumType>();                                               \
 				if (enum_type.is_valid() && PyObject_IsInstance(src.ptr(), enum_type.ptr()) == 1) {                    \

src/include/duckdb_python/numpy/numpy_array.hpp

@@ -18,14 +18,11 @@ namespace duckdb {
 namespace numpy_internal {
 
 //! Mirror of the leading fields of numpy's `PyArrayObject` (stable ABI across numpy 1.x and 2.x).
-//! Only the buffer pointer is needed. Reading `data` is a plain struct field access -- no Python
-//! call, no allocation, no GIL -- exactly what pybind11's `py::array::data()` did internally via
-//! its own equivalent proxy struct. Obtaining the pointer this way (instead of via a `ctypes.data`
-//! attribute chain) is what keeps the numpy columnar path fast for LIST/ARRAY columns, whose
-//! per-element converter allocates a fresh array per row.
+//! Reading `data` is a plain struct field access (no Python call, allocation, or GIL). Obtaining
+//! the pointer this way, instead of via a `ctypes.data` attribute chain, keeps the numpy columnar
+//! path fast for LIST/ARRAY columns, whose per-element converter allocates a fresh array per row.
 struct NumpyArrayProxy {
-	PyObject_HEAD
-	char *data;
+	PyObject_HEAD char *data;
 };
 
 //! Borrowed handle to the `numpy.ndarray` type, fetched once under the GIL and intentionally leaked
@@ -41,12 +38,10 @@ inline PyTypeObject *NumpyNdarrayType() {
 }
 
 //! Allocate an uninitialized 1-D numpy array of `count` elements with the given numpy dtype string.
-//! The bound `numpy.empty` and the `np.dtype` objects (a handful of distinct dtype strings) are
-//! cached to avoid a module import, an attribute lookup, and a dtype-string parse on every call --
-//! this is hot, since a LIST/ARRAY column allocates one array per row (pybind11 constructed the
-//! array at the C level via `py::array(py::dtype, count)`, which paid none of that). Cached handles
-//! are leaked for process lifetime (shutdown-safe: no Python destructor runs after finalization).
-//! Only ever called on the single-threaded, GIL-held result-materialization path.
+//! `numpy.empty` and the `np.dtype` objects are cached to avoid a module import, attribute lookup,
+//! and dtype-string parse on every call. This is hot: a LIST/ARRAY column allocates one array per
+//! row. Cached handles are leaked for process lifetime (shutdown-safe: no Python destructor runs
+//! after finalization). Only ever called on the single-threaded, GIL-held result path.
 inline nb::object NumpyEmpty(idx_t count, const string &dtype) {
 	static PyObject *empty_fn = []() -> PyObject * {
 		nb::object fn = nb::module_::import_("numpy").attr("empty");
@@ -69,17 +64,15 @@ inline nb::object NumpyEmpty(idx_t count, const string &dtype) {
 //! object. Under nanobind there is no `nb::array` (and no `nb::dtype`); the array is held
 //! as a plain `nb::object` and the few buffer operations go through numpy directly.
 //!
-//! Performance note: `Data()`/`MutableData()` are on the HOT path — the numpy scan calls
-//! `Data()` once per column per 2048-row chunk (see numpy_scan.cpp), and DuckDB drives that
-//! scan from multiple threads WITHOUT holding the GIL. It is also on the LIST/ARRAY result path,
-//! where a fresh array (and thus a fresh buffer pointer) is materialized per row. The pointer is
-//! read directly from the numpy array's C struct (see `numpy_internal::NumpyArrayProxy`): a plain
-//! field access, no Python call, no allocation, no GIL — exactly what pybind11's
-//! `py::array::data()` did. We compute it ONCE, eagerly, in the constructor (always invoked
-//! single-threaded with the GIL held at bind/result time) and cache it; the cache is invalidated
-//! (and recomputed) by `Resize()`, the only operation that reallocates the buffer. Reading the
-//! struct field is dtype-agnostic (works for the `object` dtype that DLPack/`nb::ndarray` cannot
-//! represent).
+//! Performance note: `Data()`/`MutableData()` are on the HOT path. The numpy scan calls `Data()`
+//! once per column per 2048-row chunk (see numpy_scan.cpp), and DuckDB drives that scan from
+//! multiple threads WITHOUT holding the GIL. It is also on the LIST/ARRAY result path, where a
+//! fresh array (and buffer pointer) is materialized per row. The pointer is read directly from the
+//! numpy array's C struct (see `numpy_internal::NumpyArrayProxy`): a plain field access, no Python
+//! call, allocation, or GIL. We compute it ONCE, eagerly, in the constructor (single-threaded with
+//! the GIL held at bind/result time) and cache it; the cache is invalidated (and recomputed) by
+//! `Resize()`, the only operation that reallocates the buffer. The struct read is dtype-agnostic
+//! (works for the `object` dtype that DLPack/`nb::ndarray` cannot represent).
 //!
 //! Ownership is move-only-when-asked: the ctor takes by value and moves, GetArray() hands
 //! back a reference, and no method copies the array buffer. The raw `cached_data_` member uses
@@ -101,8 +94,8 @@ class NumpyArray {
 
 public:
 	//! Allocate a fresh, contiguous 1-D numpy array of `count` elements with the given numpy
-	//! dtype string (e.g. "int64", "float32", "object", "datetime64[us]"). Uninitialized —
-	//! callers fill it immediately, matching the previous `nb::array(nb::dtype(d), count)`.
+	//! dtype string (e.g. "int64", "float32", "object", "datetime64[us]"). Uninitialized; callers
+	//! fill it immediately.
 	static NumpyArray Allocate(const string &dtype, idx_t count) {
 		NumpyArray result(numpy_internal::NumpyEmpty(count, dtype));
 		result.length_ = count;
@@ -127,11 +120,11 @@ class NumpyArray {
 	}
 
 	//! Resize the underlying numpy buffer in place. This REALLOCATES the buffer, so the cached
-	//! pointer is invalidated and recomputed (GIL is held -- this only runs on the single-threaded
-	//! result-materialization path). Resizing to the current length is a genuine no-op in numpy;
-	//! we skip the Python `resize` call entirely in that case (buffer and cached pointer unchanged).
-	//! The LIST/ARRAY per-element path allocates each array at its exact final size, so its
-	//! `ToArray()` shrink-to-count is always such a no-op -- hot, hence worth skipping.
+	//! pointer is invalidated and recomputed (GIL held; only runs on the single-threaded result
+	//! path). Resizing to the current length is a genuine no-op in numpy, so we skip the Python
+	//! `resize` call entirely in that case. The LIST/ARRAY per-element path allocates each array at
+	//! its exact final size, so its `ToArray()` shrink-to-count is always such a no-op: hot, worth
+	//! skipping.
 	void Resize(idx_t count) {
 		if (length_ != DConstants::INVALID_INDEX && count == length_) {
 			return;
@@ -143,7 +136,7 @@ class NumpyArray {
 	}
 
 	//! Access the underlying array, e.g. for `.attr(...)` calls, iteration, or to hand it
-	//! back to Python. Returned by reference -- never copied.
+	//! back to Python. Returned by reference, never copied.
 	nb::object &GetArray() {
 		return array;
 	}
@@ -154,8 +147,8 @@ class NumpyArray {
 private:
 	//! Compute and cache the buffer start address of the underlying numpy array, if not already
 	//! cached and a numpy ndarray is held. The pointer is read directly from the array's C struct
-	//! (dtype-agnostic, works for the `object` dtype too), matching pybind11's `py::array::data()`.
-	//! Only ever called with the GIL held (construction / Resize).
+	//! (dtype-agnostic, works for the `object` dtype too). Only ever called with the GIL held
+	//! (construction / Resize).
 	void EnsurePointer() {
 		// Some NumpyArray wrappers hold non-ndarray objects (e.g. a pandas Index) whose buffer pointer is never read.
 		// Gate the read on an actual numpy ndarray so we never reinterpret a foreign object's memory as an array.

src/native/python_conversion.cpp

@@ -1043,7 +1043,7 @@ void TransformPythonObjectInternal(optional_ptr<ClientContext> context, nb::hand
 	}
 	case PythonObjectType::Bytes: {
 		// Read the buffer directly (mirrors the ByteArray branch above): nanobind's nb::cast<std::string> rejects
-		// a bytes object (pybind11 accepted it), so go through the CPython API instead.
+		// a bytes object, so go through the CPython API instead.
 		char *bytes_buffer;
 		Py_ssize_t bytes_length;
 		PyBytes_AsStringAndSize(ele.ptr(), &bytes_buffer, &bytes_length); // NOLINT

src/native/python_objects.cpp

@@ -663,13 +663,6 @@ nb::object PythonObject::FromValue(const Value &val, const LogicalType &type,
 		auto array_size = ArrayType::GetSize(type);
 		auto &child_type = ArrayType::GetChildType(type);
 
-		// do not remove the static cast here, it's required for building
-		// duckdb-python with Emscripten.
-		//
-		// without this cast, a static_assert fails in pybind11
-		// because the return type of ArrayType::GetSize is idx_t,
-		// which is typedef'd to uint64_t and ssize_t is 4 bytes with Emscripten
-		// and pybind11 requires that the input be castable to ssize_t
 		duckdb::PyUtil::TupleBuilder arr(array_size);
 		for (idx_t elem_idx = 0; elem_idx < array_size; elem_idx++) {
 			arr.append(FromValue(array_values[elem_idx], child_type, client_properties));

src/pandas/analyzer.cpp

@@ -339,7 +339,7 @@ LogicalType PandasAnalyzer::DictToStruct(const PyDictionary &dict, bool &can_con
 
 		//! Have to already transform here because the child_list needs a string as key. Stringify via str() so
 		//! non-string keys (e.g. the integer keys of a hashable-key MAP, produced as a plain {1: 10} dict) are
-		//! accepted -- nanobind's nb::cast<std::string> rejects non-str objects, whereas pybind11 stringified them.
+		//! accepted (nb::cast<std::string> rejects non-str objects).
 		auto key = Identifier(nb::cast<std::string>(nb::str(dict_key)));
 
 		auto dict_val = dict.values.attr("__getitem__")(i);

src/pyconnection.cpp

@@ -69,7 +69,7 @@ DuckDBPyConnection::~DuckDBPyConnection() {
 		// the GIL for it so other Python threads can run. The implicit member
 		// destructors that fire after this scope (notably
 		// `registered_functions`, a `case_insensitive_map_t<unique_ptr<ExternalDependency>>`
-		// whose entries transitively own pybind-managed Python references)
+		// whose entries transitively own Python references)
 		// run with the GIL reacquired because `gil` is destroyed at the end
 		// of the inner block.
 		{
@@ -477,7 +477,7 @@ DuckDBPyConnection::RegisterScalarUDF(const string &name, const nb::callable &ud
 }
 
 void DuckDBPyConnection::Initialize(nb::handle &m) {
-	// Weak-referenceable like pybind11 (which set tp_weaklistoffset by default); nanobind requires the opt-in,
+	// nanobind types aren't weak-referenceable by default;
 	// otherwise weakref.ref/proxy/finalize on a connection raises TypeError.
 	auto connection_module = nb::class_<DuckDBPyConnection>(m, "DuckDBPyConnection", nb::is_weak_referenceable());
 
@@ -1920,7 +1920,7 @@ void DuckDBPyConnection::Close() {
 	// is pure C++ work and can take noticeable time. Hold the GIL back for
 	// `registered_functions.clear()` because the
 	// `case_insensitive_map_t<unique_ptr<ExternalDependency>>` it destroys
-	// transitively owns pybind-managed Python references (Python UDF
+	// transitively owns Python references (Python UDF
 	// callables, registered Python objects, …). Decrementing those
 	// references with the GIL released is undefined behaviour — see
 	// duckdb-python#456.
@@ -2166,7 +2166,7 @@ duckdb::pyarrow::RecordBatchReader DuckDBPyConnection::FetchRecordBatchReader(co
 case_insensitive_map_t<Value> TransformPyConfigDict(const nb::dict &py_config_dict) {
 	case_insensitive_map_t<Value> config_dict;
 	for (auto kv : py_config_dict) {
-		// Config values may be int/bool/str; str-ify them (matches pybind11's nb::str(value)) rather than
+		// Config values may be int/bool/str; str-ify them rather than
 		// requiring an actual Python str (nb::cast<std::string> would throw on a non-str like 0 or False).
 		auto key = nb::cast<std::string>(nb::str(kv.first));
 		auto val = nb::cast<std::string>(nb::str(kv.second));

src/pyexpression.cpp

@@ -353,7 +353,7 @@ bool DuckDBPyExpression::TryToExpression(nb::handle obj, std::unique_ptr<DuckDBP
 			// A str becomes a column reference, mirrors the registered str constructor.
 			result = ColumnExpression(nb::cast<nb::args>(nb::make_tuple(obj)));
 		} else if (nb::isinstance<nb::bytes>(obj)) {
-			// pybind11 decoded bytes as UTF-8 and (like str) treated them as a column reference; preserve that
+			// Decode bytes as UTF-8 and treat like str (a column reference),
 			// so e.g. rel.project(b"col") references column "col" instead of silently building a BLOB constant.
 			result = ColumnExpression(nb::cast<nb::args>(nb::make_tuple(obj.attr("decode")("utf-8"))));
 		} else {

src/pyexpression/initialize.cpp

@@ -11,9 +11,9 @@ namespace {
 // Binary operators take their operand as nb::object (not Expression) so that None can bind: nanobind rejects None for a
 // bound-type parameter before the registered implicit conversion runs, so `expr == None` / `expr + None` would never
 // reach the None -> SQL NULL conversion otherwise. We convert explicitly via TryToExpression (an existing Expression is
-// copied, a str becomes a column reference, any other value -- including None -- becomes a constant). On a genuinely
+// copied, a str becomes a column reference, any other value (including None) becomes a constant). On a genuinely
 // unconvertible operand we return Py_NotImplemented so Python falls back to the reflected operator / identity
-// comparison, exactly as the is_operator() overload did under pybind11 (keeps e.g. `expr == object()` returning False
+// comparison, keeping e.g. `expr == object()` returning False
 // instead of raising).
 template <typename Build>
 nb::object ExpressionBinaryOp(const nb::object &other, Build &&build) {
@@ -325,7 +325,7 @@ static void InitializeImplicitConversion(nb::class_<DuckDBPyExpression> &m) {
 }
 
 void DuckDBPyExpression::Initialize(nb::module_ &m) {
-	// Weak-referenceable like pybind11 (nanobind requires the explicit opt-in).
+	// nanobind types aren't weak-referenceable by default.
 	auto expression = nb::class_<DuckDBPyExpression>(m, "Expression", nb::is_weak_referenceable());
 
 	InitializeStaticMethods(m);

src/pyrelation/initialize.cpp

@@ -278,7 +278,7 @@ static void InitializeMetaQueries(nb::class_<DuckDBPyRelation> &m) {
 }
 
 void DuckDBPyRelation::Initialize(nb::handle &m) {
-	// Weak-referenceable like pybind11 (nanobind requires the explicit opt-in).
+	// nanobind types aren't weak-referenceable by default.
 	auto relation_module = nb::class_<DuckDBPyRelation>(m, "DuckDBPyRelation", nb::is_weak_referenceable());
 	InitializeReadOnlyProperties(relation_module);
 	InitializeAggregates(relation_module);

src/pyresult.cpp

@@ -37,7 +37,7 @@ DuckDBPyResult::DuckDBPyResult(unique_ptr<QueryResult> result_p) : result(std::m
 
 DuckDBPyResult::~DuckDBPyResult() {
 	// The destructor must run with the GIL held: `result` and `current_chunk`
-	// can transitively own pybind-managed Python references (registered
+	// can transitively own Python references (registered
 	// objects, arrow release callbacks, PYTHON_OBJECT vector values, etc.),
 	// whose teardown calls into the Python C API. Releasing the GIL here
 	// (as the previous implementation did) causes Py_DECREF / PyObject_Free