I'll prepare removal of __getformat__ in a separate commit.

Edit: Mark Dickinson suggested to keep this for alternative Python implementations.

cc @diegorusso

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

And if you don't make the requested changes, you will be put in the comfy chair!

This is more a generic question about the process. Shouldn't we follow the usual removal process (warning + removal)? In this specific case, it might be still OK just to drop it as I really doubt these that the OS on these old devices wants to ship Python 3.15.

I reply to my own question. This is not a language change hence safe to remove. Also the probability that this will affect users is extremely low.

Shouldn't we follow the usual removal process (warning + removal)? In this specific case, it might be still OK just to drop it as I really doubt these that the OS on these old devices wants to ship Python 3.15.

A bit of history, 2a9c380 (eight years ago) says:

RFC because this doesn't yet handle the weird ancient ARMv4 OABI 'mixed-endian' encoding properly. This encoding is ancient and I don't believe the union of "Python 3.8 users" and "OABI users" has anything in. Should the support for this just be dropped too?

I'm OK to make first deprecation. Though, at least lets not wait too much (aka "preferred" scenario per PEP 387).

But honestly, I don't see big reason to delay removal. You know much more about ARM world, can we have any practical use case here?

The struct in pycore_runtime_structs.h still has the _py_float_format_unknown We should remove it from there as well.

Yes, I just removed all logic for handling float_state in favor of macros. BTW, maybe we could just use platform endianness?

I have made the requested changes; please review again.

Thanks for making the requested changes!

@diegorusso: please review the changes made to this pull request.

@vstinner, what do you think on using platform endianness?

Current version assumes, that endianness for floating-point numbers can be different wrt sys.byteorder. This is odd and is not true for anything mentioned in the PEP 11.

@vstinner, what do you think on using platform endianness? Current version assumes, that endianness for floating-point numbers can be different wrt sys.byteorder. This is odd and is not true for anything mentioned in the PEP 11.

If you want to remove DOUBLE_IS_BIG_ENDIAN_IEEE754 and DOUBLE_IS_LITTLE_ENDIAN_IEEE754, I suggest doing it in a separated issue. I'm not bothered by these macros, we have to handle endianness somehow anyway.