Skip to content

Commit f4fec4c

Browse files
authored
Merge branch 'main' into patch-1
2 parents 16d4d2c + 52c0186 commit f4fec4c

20 files changed

Lines changed: 1084 additions & 1016 deletions

Doc/c-api/buffer.rst

Lines changed: 3 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -500,10 +500,11 @@ Buffer-related functions
500500
*indices* must point to an array of ``view->ndim`` indices.
501501
502502
503-
.. c:function:: int PyBuffer_FromContiguous(const Py_buffer *view, const void *buf, Py_ssize_t len, char fort)
503+
.. c:function:: int PyBuffer_FromContiguous(const Py_buffer *view, const void *buf, Py_ssize_t len, char order)
504504
505505
Copy contiguous *len* bytes from *buf* to *view*.
506-
*fort* can be ``'C'`` or ``'F'`` (for C-style or Fortran-style ordering).
506+
*order* can be ``'C'`` or ``'F'`` or ``'A'`` (for C-style or Fortran-style
507+
ordering or either one).
507508
``0`` is returned on success, ``-1`` on error.
508509
509510

Doc/c-api/float.rst

Lines changed: 23 additions & 18 deletions
Original file line numberDiff line numberDiff line change
@@ -190,24 +190,23 @@ The pack and unpack functions provide an efficient platform-independent way to
190190
store floating-point values as byte strings. The Pack routines produce a bytes
191191
string from a C :c:expr:`double`, and the Unpack routines produce a C
192192
:c:expr:`double` from such a bytes string. The suffix (2, 4 or 8) specifies the
193-
number of bytes in the bytes string.
193+
number of bytes in the bytes string:
194194
195-
On platforms that appear to use IEEE 754 formats these functions work by
196-
copying bits. On other platforms, the 2-byte format is identical to the IEEE
197-
754 binary16 half-precision format, the 4-byte format (32-bit) is identical to
198-
the IEEE 754 binary32 single precision format, and the 8-byte format to the
199-
IEEE 754 binary64 double precision format, although the packing of INFs and
200-
NaNs (if such things exist on the platform) isn't handled correctly, and
201-
attempting to unpack a bytes string containing an IEEE INF or NaN will raise an
202-
exception.
195+
* The 2-byte format is the IEEE 754 binary16 half-precision format.
196+
* The 4-byte format is the IEEE 754 binary32 single-precision format.
197+
* The 8-byte format is the IEEE 754 binary64 double-precision format.
203198
204-
Note that NaN type may not be preserved on IEEE platforms (signaling NaNs become
205-
quiet NaNs), for example on x86 systems in 32-bit mode.
199+
The NaN type may not be preserved on some platforms while unpacking (signaling
200+
NaNs become quiet NaNs), for example on x86 systems in 32-bit mode.
206201
202+
It's assumed that the :c:expr:`double` type has the IEEE 754 binary64 double
203+
precision format. What happens if it's not true is partly accidental (alas).
207204
On non-IEEE platforms with more precision, or larger dynamic range, than IEEE
208205
754 supports, not all values can be packed; on non-IEEE platforms with less
209-
precision, or smaller dynamic range, not all values can be unpacked. What
210-
happens in such cases is partly accidental (alas).
206+
precision, or smaller dynamic range, not all values can be unpacked. The
207+
packing of special numbers like INFs and NaNs (if such things exist on the
208+
platform) may not be handled correctly, and attempting to unpack a bytes string
209+
containing an IEEE INF or NaN may raise an exception.
211210
212211
.. versionadded:: 3.11
213212
@@ -217,9 +216,9 @@ Pack functions
217216
The pack routines write 2, 4 or 8 bytes, starting at *p*. *le* is an
218217
:c:expr:`int` argument, non-zero if you want the bytes string in little-endian
219218
format (exponent last, at ``p+1``, ``p+3``, or ``p+6`` and ``p+7``), zero if you
220-
want big-endian format (exponent first, at *p*). The :c:macro:`PY_BIG_ENDIAN`
221-
constant can be used to use the native endian: it is equal to ``1`` on big
222-
endian processor, or ``0`` on little endian processor.
219+
want big-endian format (exponent first, at *p*). Use the :c:macro:`!PY_LITTLE_ENDIAN`
220+
constant to select the native endian: it is equal to ``0`` on big
221+
endian processor, or ``1`` on little endian processor.
223222
224223
Return value: ``0`` if all is OK, ``-1`` if error (and an exception is set,
225224
most likely :exc:`OverflowError`).
@@ -236,21 +235,27 @@ most likely :exc:`OverflowError`).
236235
237236
Pack a C double as the IEEE 754 binary64 double precision format.
238237
238+
.. impl-detail::
239+
This function always succeeds in CPython.
240+
239241
240242
Unpack functions
241243
^^^^^^^^^^^^^^^^
242244
243245
The unpack routines read 2, 4 or 8 bytes, starting at *p*. *le* is an
244246
:c:expr:`int` argument, non-zero if the bytes string is in little-endian format
245247
(exponent last, at ``p+1``, ``p+3`` or ``p+6`` and ``p+7``), zero if big-endian
246-
(exponent first, at *p*). The :c:macro:`PY_BIG_ENDIAN` constant can be used to
247-
use the native endian: it is equal to ``1`` on big endian processor, or ``0``
248+
(exponent first, at *p*). Use the :c:macro:`!PY_LITTLE_ENDIAN` constant to
249+
select the native endian: it is equal to ``0`` on big endian processor, or ``1``
248250
on little endian processor.
249251
250252
Return value: The unpacked double. On error, this is ``-1.0`` and
251253
:c:func:`PyErr_Occurred` is true (and an exception is set, most likely
252254
:exc:`OverflowError`).
253255
256+
.. impl-detail::
257+
These functions always succeed in CPython.
258+
254259
.. c:function:: double PyFloat_Unpack2(const char *p, int le)
255260
256261
Unpack the IEEE 754 binary16 half-precision format as a C double.

Doc/tools/.nitignore

Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -3,7 +3,6 @@
33
# Keep lines sorted lexicographically to help avoid merge conflicts.
44

55
Doc/c-api/descriptor.rst
6-
Doc/c-api/float.rst
76
Doc/c-api/init_config.rst
87
Doc/c-api/intro.rst
98
Doc/c-api/stable.rst

Include/internal/pycore_opcode_metadata.h

Lines changed: 2 additions & 2 deletions
Some generated files are not rendered by default. Learn more about customizing how changed files appear on GitHub.

0 commit comments

Comments
 (0)