From cee104db8606797a63752d2904b2f2795014a125 Mon Sep 17 00:00:00 2001 From: Wenzel Jakob Date: Sat, 11 Jan 2025 17:17:33 +0900 Subject: [PATCH] minor documentation tweaks --- docs/changelog.rst | 24 +++++++++++++++--------- docs/faq.rst | 26 ++++++++++++++++++-------- 2 files changed, 33 insertions(+), 17 deletions(-) diff --git a/docs/changelog.rst b/docs/changelog.rst index 175ad804..2fa4da02 100644 --- a/docs/changelog.rst +++ b/docs/changelog.rst @@ -18,7 +18,8 @@ below inherit that of the preceding release. Version TBD (not yet released) ------------------------------ -- Added some special forms for :cpp:class:`nb::typed\ `: +- Added some special forms for :cpp:class:`nb::typed\ ` + (PR `#835 `__): - ``nb::typed`` or ``nb::typed`` produces a parameter or return value that will be described like ``T`` in function @@ -28,8 +29,6 @@ Version TBD (not yet released) ``Callable[[Args...], R]``; similarly, ``nb::typed`` (with a literal ellipsis) produces the Python ``Callable[..., R]``. - (PR `#835 `__). - - Fixed the :cpp:class:`nb::int_ ` constructor so that it casts to an integer when invoked with a floating point argument. @@ -38,17 +37,24 @@ Version TBD (not yet released) `__). - Fixed a race condition in free-threaded extensions that could occur when - :cpp:func:`nb::make_iterator ` concurrently used by + :cpp:func:`nb::make_iterator ` was concurrently used by multiple threads (PR `#832 `__). - Removed double-checked locking patterns in accesses to internal data structures to ensure correct free-threaded behavior on architectures with - weak memory ordering (specifically, ARM). (PR `#819 + weak memory ordering such as ARM (PR `#819 `__). - -- The floating-point type_caster now only performs value-changing narrowing - conversions if the convert flag is set. - (PR `#829 `__) + +- The floating-point type caster now only performs value-changing narrowing + conversions during the implicit conversion phase. They can be entirely + avoided by passing the :cpp:func:`.noconvert() ` argument + annotation (PR `#829 `__). + +- Fixed an overly strict check that could cause a function taking an + :cpp:class:`nb::ndarray\<...\> ` to refuse specific types of + column-major input without implicit conversion. (PR `#847 + `__, commit `b95eb7 + `__). Version 2.4.0 (Dec 6, 2024) --------------------------- diff --git a/docs/faq.rst b/docs/faq.rst index 48819d42..1fb890b7 100644 --- a/docs/faq.rst +++ b/docs/faq.rst @@ -372,6 +372,16 @@ For Googlers: there is already an exemption from the internal rules that specifically permits the use of RTTI/exceptions when a project relies on pybind11. Likely, this exemption could be extended to include nanobind as well. +Can I make stable ABI extensios for pre-3.12 Python? +---------------------------------------------------- + +Stable ABI extensions are convenient because they can be reused across Python +versions, but this unfortunately only works on Python 3.12 and newer. Nanobind +crucially depends on several `features +`__ that were added +in version 3.12 (specifically, `PyType_FromMetaclass()`` and limited API +bindings of the vector call protocol). + I'd like to use this project, but with $BUILD_SYSTEM instead of CMake --------------------------------------------------------------------- @@ -419,14 +429,14 @@ the documentation. Are there tools to generate nanobind bindings automatically? ------------------------------------------------------------ -`litgen `__ is an automatic Python bindings -generator compatible with both pybind11 and nanobind, designed to create -documented and easily discoverable bindings. -It reproduces header documentation directly in the bindings, making the -generated API intuitive and well-documented for Python users. -Powered by srcML (srcml.org), a high-performance, multi-language parsing tool, -litgen takes a developer-centric approach. -The C++ API to be exposed to Python must be C++14 compatible, although the +`litgen `__ is an automatic Python bindings +generator compatible with both pybind11 and nanobind, designed to create +documented and easily discoverable bindings. +It reproduces header documentation directly in the bindings, making the +generated API intuitive and well-documented for Python users. +Powered by srcML (srcml.org), a high-performance, multi-language parsing tool, +litgen takes a developer-centric approach. +The C++ API to be exposed to Python must be C++14 compatible, although the implementation can leverage more modern C++ features. How to cite this project?