Remove "unknown_format" code path in PyFloat_Pack/Unpack*()

This is a follow-up of the #91073. Proposal was briefly discussed in the referenced issue.

Now support for IEEE floating-point formats is a requirement and the configure script will fail, if it can't detect it. The only exception is some ARM platforms (this come from b08a53a):

cpython/configure.ac

Lines 6172 to 6180 in 149c465

    
                      [*arm*], [# Some ARM platforms use a mixed-endian representation for 
        
                                # doubles. While Python doesn't currently have full support 
        
                                # for these platforms (see e.g., issue 1762561), we can at 
        
                                # least make sure that float <-> string conversions work. 
        
                                # FLOAT_WORDS_BIGENDIAN doesn't actually detect this case, 
        
                                # but if it's not big or little, then it must be this? 
        
                                AC_DEFINE([DOUBLE_IS_ARM_MIXED_ENDIAN_IEEE754], [1], 
        
                                          [Define if C doubles are 64-bit IEEE 754 binary format, 
        
                                           stored in ARM mixed-endian order (byte order 45670123)])],

This is only case, when "unknown_format" code patch now could be triggered (BTW, we could detect this format in runtime and switch to yet another "just copy bytes" path). Should we keep this for an unsupported platform? IIRIC, such chips aren't supported even in Debian.

With "unknown_format" we also could drop code to detect endianness in runtime. I'm not sure about float.__getformat__ function. It's docstring says:

>>> help(float.__getformat__)
Help on built-in function __getformat__:

__getformat__(typestr, /) class method of builtins.float
    You probably don't want to use this function.

      typestr
        Must be 'double' or 'float'.

    It exists mainly to be used in Python's test suite.

    This function returns whichever of 'unknown', 'IEEE, big-endian' or 'IEEE,
    little-endian' best describes the format of floating-point numbers used by the
    C type named by typestr.

Probably, it could be treated as private and we should remove it in favor of using configure macros in tests. (__set_format__() method was removed without prior deprecation in 5ab745f). Edit: we could also leave this also as-is for alternative Python implementations, using CPython tests.

Linked PRs

@vstinner

CC @vstinner

I tried but failed to remove this code.

Do you remember why?

pythongh-145633: remove support for ancient ARM platforms with mixed-…

@diegorusso

cc @diegorusso

I tried but failed to remove this code.

Do you remember why?

I don't recall exactly. I think that I didn't understand well which platforms use "unknown format" and I was afraid of breaking anything.

I tried but failed to remove this code.

Do you remember why?

I don't recall exactly. I think that I didn't understand well which platforms use "unknown format" and I was afraid of breaking anything.

Before merging, should we run the PR attaches via buildbot?

pythongh-145633: Drop runtime checks for floatting-point formats in t…

pythongh-145633: Remove remnants of the "unknown_format" (floats) in …

pythongh-145633: Fix struct.pack('f') on s390x (python#146422)

I agree with dropping untested code, but I don't think we should prevent porting CPython to old (or future) non-IEEE platforms.

The only way to do this is to revert choice made. Thread: https://mail.python.org/archives/list/python-dev@python.org/thread/J5FSP6J4EITPY5C2UJI7HSL2GQCTCUWN/

I would say it will be a step backward.

pythongh-145633: Remove support for ancient ARM platforms with mixed-…

pythongh-145633: Refine notes on non-IEEE platforms (python#145845)

pythongh-145633: Drop runtime checks for floatting-point formats in t…

pythongh-145633: Remove remnants of the "unknown_format" (floats) in …

pythongh-145633: Fix struct.pack('f') on s390x (python#146422)

https://discuss.python.org/t/deprecate-float-getformat/107151 - discussion of __getformat__ removal.

Lets close this. If someone wish to continue - it would be better to open a new issue.

I opened one in the C API WG repo: capi-workgroup/decisions#107

gh-145633: Allow PyFloat_Pack8 & PyFloat_UnPack* to fail in future CP…

[3.15] gh-145633: Allow PyFloat_Pack8 & PyFloat_UnPack* to fail in fu…

Navigation Menu

Repository navigation

Remove "unknown_format" code path in PyFloat_Pack/Unpack*() #145633

Linked PRs

37 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

	[arm], [# Some ARM platforms use a mixed-endian representation for
	# doubles. While Python doesn't currently have full support
	# for these platforms (see e.g., issue 1762561), we can at
	# least make sure that float <-> string conversions work.
	# FLOAT_WORDS_BIGENDIAN doesn't actually detect this case,
	# but if it's not big or little, then it must be this?
	AC_DEFINE([DOUBLE_IS_ARM_MIXED_ENDIAN_IEEE754], [1],
	[Define if C doubles are 64-bit IEEE 754 binary format,
	stored in ARM mixed-endian order (byte order 45670123)])],

Remove "unknown_format" code path in PyFloat_Pack/Unpack*() #145633

Description

Linked PRs

Activity

skirpichev commented on Mar 8, 2026

corona10 commented on Mar 8, 2026

vstinner commented on Mar 9, 2026

diegorusso commented on Mar 9, 2026

37 remaining items

encukou commented on Apr 17, 2026

skirpichev commented on Apr 17, 2026

skirpichev commented on May 4, 2026

encukou commented on Jun 15, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions