Accept more hexstring formats in `binascii.unhexlify` and `bytes.fromhex`

[kohlrabi]

Feature or enhancement

Proposal:

Currently both binascii.hexlify and bytes.hex offer the options to set the separator and the bytes-per-separator.

The inverse functions for both, binascii.unhexlify and bytes.fromhex respectively, do not offer these switches though, and do not ignore non-hexstring [^0-9A-Fa-f] characters either (bytes.fromhex at least ignores whitespace, but only that).

Both should be improved to either ignore any non-hexstring characters, or have the options to set the separator and bytes-per-separator (like the inverse functions), or some other method to enable them to work with any hexstrings that can be generated by their inverse functions.

I am willing to look into this issue and implement either suggested method or something else entirely.

Has this already been discussed elsewhere?

No response given

Links to previous discussion of this feature:

No response

[ericvsmith]

They definitely should not ignore any non-hexstring characters. We would not want "It's n0 prob" to return 0.

[kohlrabi]

True, that was shortsighted (Though arguably your string does not have a full byte in it, but I get the point, "no pr0b"). But I think any of the hexstrings with delimiters written by bytes.hex should be somehow readable by these functions with having to prepare the strings using other methods first.

[ericvsmith]

I agree it would be nice to round-trip the values. The trick is coming up with a good API that doesn't accept invalid strings.

It's probably worth discussing this on discuss.python.org.

[picnixz]

Most of the time, specifying separators is meant for prettification, not for machine-readable format so striving for a round trip is not necessary IMO. I do not want to ignore non-hex strings unless they are spaces (which is handled by fromhex() but not unhexlify()).

unhexlify() requires a stricter format because the even-length assumption is used for performance reasons (see #131171). So adding more liberal formats would likely impact performance.

I'm going to close this issue for now because I don't think we should keep it open unless a DPO thread has been opened and consensus and support has been built. Once this has been done, I'll reopen the issue if needed. Alternatively, one suggestion I have is that we add a more generic and separate function for dumping bytes into hexstrings and vice-versa, but that again may be an overkill (I really don't want to have 3 interfaces for writing hexstrings honestly).