DuckPlus 1.4.7#
DuckPlus 1.4.7 finalises the 1.4 series by locking the static typed contracts to what ships on PyPI. The ty and mypy suites now exercise the entire static-typed API surface, and the release gate demands 100 percent parity so editor integrations stay aligned with runtime behaviour. Unsigned integer factories are exported alongside the rest of the numeric hierarchy and type-casting now infers their DuckDB representations automatically, rounding out the migration away from generated registries.
Earlier 1.4.x releases extended the direct-Python helper strategy to DuckDB’s
scalar macro surface so decorator-backed modules now publish the split_part
family, array helpers, and PostgreSQL catalog shims. The static typed API
imports those modules during package initialisation, ensuring both runtime and
typed namespaces resolve the real helper implementations instead of the
generated function catalog. The macro helpers remain bound to their expression
classes, enabling fluent method calls like
ducktype.Generic("items").array_to_string(", ") without dropping down to the
namespace objects. Documentation and package metadata highlight the macro
migration so contributors can rely on the override modules when exploring the
function surface.
Tip
All code snippets in the 1.4 guides run against the duckplus package
published on PyPI. They assume Python 3.11+ and DuckDB 0.10+; if you are pinned
to an older runtime, consult the ../typed_api appendix for migration
notes and breaking-change callouts.
Release highlights#
Ty and mypy parity contracts – Version-gated integration tests now enforce 100 percent agreement between the type checkers and the runtime API surface, ensuring editors surface every helper and diagnostic that succeeds in Python.
Unsigned integer factory exports –
Uinteger,Usmallint, andUtinyintfactories are public package members, and casting derives their DuckDB types automatically so literal parsing and expression casts stay consistent.Decorator-backed scalar macros – DuckPlus 1.4 adds :mod:
duckplus.functions.scalarmodules for string, list, PostgreSQL catalog, privilege, and visibility macros. Import-time decorators register overloads on the correct namespaces so IDEs and documentation resolve the Python implementations instead of generated metadata.Fluent macro chaining – Static typed overrides now attach string and array macros directly to their corresponding expression classes (for example,
VarcharExpression.split_partandGenericExpression.array_to_string), so user code can chain helpers without manually referencing the typed namespaces.Typed namespace override coverage – :mod:
duckplus.static_typednow imports the macro override package by default, replacing the generated entries with the decorator-backed helpers as soon as the typed namespace loads. Regression tests pin helper provenance so future migrations stay honest.Documentation alignment for macros – the Sphinx build and release guides describe the new macro buckets and link directly to the override modules so contributors can find the canonical implementations without spelunking through generated sources.
The sections below walk through the features in increasing depth. Jump straight to the area you care about or read sequentially to build a mental model of the entire stack.
Start here
If you are upgrading from DuckPlus 1.3, the Getting started chapter
highlights the stable import paths while the deep-dive guides explain how each
helper composes with DuckDB. The derived :doc:practitioner_demos include a
DuckDB parity checklist that mirrors the interactive demo site, and the
expanded :doc:core/function_modules page documents the direct-Python helper
catalog so static tooling and application developers can reason about DuckPlus
without inspecting the generated sources.