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

[skirpichev]

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

---

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

[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]

Would not be better to first add a field to sys.version_info?

@serhiy-storchaka, not sure I get this part of you proposal. Could you elaborate?

[vstinner]

Would not be better to first add a field to sys.version_info?

Do you mean sys.float_info? Which members do you want to add?

new code

[skirpichev]

@vstinner, could you review the new version? I removed using ctypes in favor of the struct module.

Do you mean sys.float_info? Which members do you want to add?

@serhiy-storchaka suggestion doesn't look clear for me as well. I'm not sure about meaning of the new option/flag.

[serhiy-storchaka]

Yes, I meant sys.float_info, sorry.

If HAVE_IEEE_754 is always true, should not we get rid of requires_IEEE_754()? If it can still be false (what about WASM or other exotic builds?), then we need to provide the user with such information. 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.

[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.