gh-85989: deprecate float.__getformat__() class method

[skirpichev]

---

📚 Documentation preview 📚: https://cpython-previews--146400.org.readthedocs.build/

• Issue: Add more fields to sys.float_info #85989

[skirpichev]

CC @serhiy-storchaka

[vstinner]

LGTM

[skirpichev]

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

[serhiy-storchaka]

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.

[skirpichev]

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.

[mwhudson]

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.

[skirpichev]

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.

[serhiy-storchaka]

Would not be better to first add a field to sys.version_info? Then, few versions late, we can deprecate float.__getformat__().

[skirpichev]

If it can still be false (what about WASM or other exotic builds?), then we need to provide the user with such information.

It can be false for other Python implementations, using the CPython test suite.

And I think a public field in sys.float_info is better than private method of float. It can also be a separate sys member, like sys.byteorder.

It can, but what this will mean?

[serhiy-storchaka]

float.__getformat__() answers two questions. Is the implementation uses IEEE 754? Is it big-endian or little-endian? It seems that our tests only need the former, and the answer is always yes in CPython. So we can add a boolean flag is_ieee_754. Users may need to also know the endianess. Did you search how float.__getformat__() is used in third-party code? Anyway, I think that deprecation and then removing such feature needs a wider discussion.

[skirpichev]

Is the implementation uses IEEE 754?

I'm not sure that it means. The former test just check a random finite number. Does this ensure that we have support for infinities and nans? Have subnormals? I proposed to expose __STDC_IEC_559__ macro (#138580), but that was apparently a bad idea.

Is it big-endian or little-endian?

I don't think there are cases, where sys.byteorder not cover this.

So we can add a boolean flag is_ieee_754.

And it's meaning?.. I think we may want flag like __STDC_IEC_559__, but this is something that can't be tested easily.

Did you search how float.getformat() is used in third-party code?

Victor did. I think this fits above conclusion (using for tests).

I think that deprecation and then removing such feature needs a wider discussion.

Ok, I'm going to close this pr, unless there are other opinions.

[serhiy-storchaka]

Don't close, just open a discussion on https://discuss.python.org/, wait a week, and then we will see if there are any serious ideas or arguments for or against the deprecation.

[skirpichev]

Don't close, just open a discussion on https://discuss.python.org/, wait a week

See https://discuss.python.org/t/deprecate-float-getformat/107151.

Sadly, this couldn't enter v3.15.

[read-the-docs-community]

Documentation build overview

📚 cpython-previews | 🛠️ Build #33897875 | 📁 Comparing 1389d58 against main (2a07ff9)

  🔍 Preview build  

301 files changed · + 9 added · ± 291 modified · - 1 deleted

+ Added

• c-api/sentinel.html
• c-api/slots.html
• deprecations/pending-removal-in-3.21.html
• howto/abi3t-migration.html
• library/asyncio-threading.html
• library/asyncio-tools.html
• library/tkinter.fontchooser.html
• library/tkinter.systray.html
• whatsnew/3.16.html

± Modified

• bugs.html
• glossary.html
• index.html
• license.html
• py-modindex.html
• c-api/allocation.html
• c-api/buffer.html
• c-api/bytes.html
• c-api/code.html
• c-api/complex.html
• and 281 more...

- Deleted

• library/asyncio-policy.html

[skirpichev]

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.

[skirpichev]

@sobolevn, any idea why now test_detach_materialized_dict_no_memory() fails on this pr? Looks entirely unrelated to it's content.