CC @serhiy-storchaka

@vstinner, please don't merge. I would appreciate a second review.

in general, I like removing private, unsystematic, undocumented methods which only serve internal debugging purpose. There some things in bytearray and set. But first we need to look at their history and ask authors who added them. Do they still need them? I think that special testing module would be better place for such things.

But first we need to look at their history and ask authors who added them. Do they still need them?

The __getformat__() class method, together with removed __setformat__() was added by ba283e2. CC @mwhudson

I think that special testing module would be better place for such things.

This private API now is helpful only for alternative implementations, which run the CPython test suite. I don't see how a special testing module would help here.

See #145633 (comment) for some usage examples.

But first we need to look at their history and ask authors who added them. Do they still need them?

The __getformat__() class method, together with removed __setformat__() was added by ba283e2. CC @mwhudson

Oh dear me that was nearly 21 years ago! Unsurprisingly the details have faded a bit but I'm pretty sure this was around making struct.{pack,unpack} work with NaNs and infs and such. If Python requires IEEE 754 to build then I think it can all be regarded as historical fluff and deprecated then deleted.

If Python requires IEEE 754 to build then I think it can all be regarded as historical fluff and deprecated then deleted.

The problem is that the CPython test suite used in alternative implementations, like PyPy. In principle they may not require IEEE-compatible formats for floats.

That's why @mdickinson suggested to keep requires_IEEE_754 decorator. Which, in turn, needs something to check that this requirement is satisfied. New helper does same checks as before, if ctypes module is available.

Documentation build overview

📚 cpython-previews | 🛠️ Build #34586951 | 📁 Comparing 9875045 against main (2a07ff9)

  🔍 Preview build  

+ Added

• builtins/constants.html
• builtins/exceptions.html
• builtins/functions.html
• builtins/index.html
• builtins/stdtypes.html
• builtins/threadsafety.html
• builtins/time-complexity.html
• c-api/sentinel.html
• c-api/slots.html
• deprecations/pending-removal-in-3.21.html
• and 8 more...

± Modified

• bugs.html
• glossary.html
• index.html
• license.html
• py-modindex.html
• c-api/allocation.html
• c-api/arg.html
• c-api/bool.html
• c-api/buffer.html
• c-api/bytearray.html
• and 425 more...

- Deleted

• library/asyncio-policy.html
• library/dialog.html

then we will see if there are any serious ideas or arguments for or against the deprecation.

I think there aren't, no?

The sys.float_info also restricts it's scope to the float.h header. Lets not break it without good reasons. The C standard now have DBL_IS_IEC_60559 flag here, but it doesn't indicate something like conformance to the IEEE 754 double format. We can expose this, but I doubt it's a replacement for the current test.

I don't think that you can simply deprecate (and later remove) float.__getformat__() with no replacement.

We need a replacement like sys.float_info.ieee_754 which would be used by @support.requires_IEEE_754.

See the SC decision: capi-workgroup/decisions#107 (comment).

Can you write a first PR to add sys.float_info.ieee_754?

I don't think that you can simply deprecate (and later remove) float.__getformat__() with no replacement.

__getformat__() was private, testing-only API. We have replacement for this: it's current PR with a helper for tests.

We need a replacement like sys.float_info.ieee_754 which would be used by @support.requires_IEEE_754. Can you write a first PR to add sys.float_info.ieee_754?

What this flag (?) will mean? Current testing helper has no clear meaning, it's a poor-mans replacement for __STDC_IEC_559__ define.

@vstinner, should I restore #138811 with a correction that if __STDC_IEC_559__ is not defined - we fallback on the __getformat__() code, instead? (Maybe flag should be renamed to ieee_754.)

I worry, that we could have false positives on this road. As Mark said in the issue thread, we have no reliable way to tell whether floats use IEEE 754 (I don't see any other appropriate meaning for the new flag).