gh-154568: Fix array._array_reconstructor() ignoring requested byte order for float16

The slow-path decoder for IEEE_754_FLOAT16_LE/BE computed the
byte-order flag by comparing mformat_code against IEEE_754_FLOAT_LE
(the 32-bit float constant) instead of IEEE_754_FLOAT16_LE. Since the
float16 mformat codes are never equal to that constant, the comparison
was always false, so the decoder always treated input as big-endian
regardless of what was requested.

Adds a regression test. A real 'e'-typecode array only exercises the
slow/converting path when the requested mformat disagrees with the
machine's native float16 format, so which direction (LE/BE) exercises
the buggy branch depends on the test machine's endianness, and the
other direction happens to come out "correct" by coincidence since the
bug unconditionally decodes as big-endian. The test uses a typecode
('d') whose native format can never match the float16 codes, forcing
the slow path deterministically on any machine.

Author: PhysicistJohn

Lib/test/test_array.py

@@ -239,6 +239,28 @@ def test_numbers(self):
                 self.assertEqual(a, b,
                     msg="{0!r} != {1!r}; testcase={2!r}".format(a, b, testcase))
 
+    def test_float16_endianness(self):
+        # gh-issue: the slow-path decoder for IEEE_754_FLOAT16_LE/BE
+        # compared mformat_code against the 32-bit float constant
+        # (IEEE_754_FLOAT_LE) instead of the float16 one, so it always
+        # decoded as big-endian regardless of what was requested.
+        #
+        # A real 'e'-typecode array only exercises the slow (converting)
+        # path when the requested mformat disagrees with the *native*
+        # float16 format, so which of LE/BE actually exercises the buggy
+        # branch depends on the test machine's endianness, and the other
+        # direction happens to come out "correct by coincidence" because
+        # the bug unconditionally decodes as big-endian. Using a
+        # typecode ('d') whose native mformat can never match
+        # IEEE_754_FLOAT16_LE/BE forces the slow path deterministically
+        # on any machine, so both directions are actually exercised.
+        le_bytes = struct.pack('<e', 1.0)
+        be_bytes = struct.pack('>e', 1.0)
+        b_le = array_reconstructor(array.array, 'd', IEEE_754_FLOAT16_LE, le_bytes)
+        b_be = array_reconstructor(array.array, 'd', IEEE_754_FLOAT16_BE, be_bytes)
+        self.assertEqual(b_le.tolist(), [1.0])
+        self.assertEqual(b_be.tolist(), [1.0])
+
     def test_unicode(self):
         teststr = "Bonne Journ\xe9e \U0002030a\U00020347"
         testcases = (

Misc/NEWS.d/next/Library/2026-07-23-21-00-00.gh-issue-154568.float16-reconstructor.rst

@@ -0,0 +1,8 @@
+Fix :func:`array._array_reconstructor` (used internally for unpickling
+:class:`array.array`) ignoring the requested byte order for the
+``IEEE_754_FLOAT16_LE``/``IEEE_754_FLOAT16_BE`` machine format codes: it
+compared against the 32-bit float constant instead of the float16 one, so
+it always decoded as big-endian regardless of what was requested. This
+could silently produce wrong values when unpickling an ``'e'``-typecode
+(half precision float) array on a machine with different native
+endianness than the one that pickled it.

Modules/arraymodule.c

@@ -2281,7 +2281,7 @@ array__array_reconstructor_impl(PyObject *module, PyTypeObject *arraytype,
     case IEEE_754_FLOAT16_LE:
     case IEEE_754_FLOAT16_BE: {
         Py_ssize_t i;
-        int le = (mformat_code == IEEE_754_FLOAT_LE) ? 1 : 0;
+        int le = (mformat_code == IEEE_754_FLOAT16_LE) ? 1 : 0;
         Py_ssize_t itemcount = Py_SIZE(items) / 2;
         const char *memstr = PyBytes_AS_STRING(items);