minor documentation tweaks

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\<T, Ts...\> <typed>`:
+- Added some special forms for :cpp:class:`nb::typed\<T, Ts...\> <typed>`
+  (PR `#835 <https://github.com/wjakob/nanobind/pull/835>`__):
 
   - ``nb::typed<nb::object, T>`` or ``nb::typed<nb::handle, T>`` 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<nb::callable, R(...)>``
     (with a literal ellipsis) produces the Python ``Callable[..., R]``.
 
-  (PR `#835 <https://github.com/wjakob/nanobind/pull/835>`__).
-
 - Fixed the :cpp:class:`nb::int_ <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)
   <https://github.com/wjakob/nanobind/commit/fb815762fdb8476cfd293e3717ca41c8bb890437>`__).
 
 - Fixed a race condition in free-threaded extensions that could occur when
-  :cpp:func:`nb::make_iterator <make_iterator>` concurrently used by
+  :cpp:func:`nb::make_iterator <make_iterator>` was concurrently used by
   multiple threads (PR `#832 <https://github.com/wjakob/nanobind/pull/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
   <https://github.com/wjakob/nanobind/pull/819>`__).
-
-- The floating-point type_caster now only performs value-changing narrowing
-  conversions if the convert flag is set.
-  (PR `#829 <https://github.com/wjakob/nanobind/pull/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() <arg::noconvert>` argument
+  annotation (PR `#829 <https://github.com/wjakob/nanobind/pull/829>`__).
+
+- Fixed an overly strict check that could cause a function taking an
+  :cpp:class:`nb::ndarray\<...\> <ndarray>` to refuse specific types of
+  column-major input without implicit conversion. (PR `#847
+  <https://github.com/wjakob/nanobind/pull/847>`__, commit `b95eb7
+  <https://github.com/wjakob/nanobind/commit/b95eb755b5a651a40562002be9ca8a4c6bf0acb9>`__).
 
 Version 2.4.0 (Dec 6, 2024)
 ---------------------------

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
+<https://docs.python.org/3/whatsnew/3.12.html#c-api-changes>`__ 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 <https://pthom.github.io/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 <https://pthom.github.io/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?