bpo-46906: Mention PY_BIG_ENDIAN in PyFloat_Pack8() doc #31832
Conversation
|
I noticed that PY_BIG_ENDIAN can be used while writing a PR for bitstruct :-) https://github.com/eerimoq/bitstruct/pull/26/files |
| @@ -109,7 +109,8 @@ Pack functions | |||
| The pack routines write 2, 4 or 8 bytes, starting at *p*. *le* is an | |||
| :c:type:`int` argument, non-zero if you want the bytes string in little-endian | |||
| format (exponent last, at ``p+1``, ``p+3``, or ``p+6`` ``p+7``), zero if you | |||
| want big-endian format (exponent first, at *p*). | |||
| want big-endian format (exponent first, at *p*). Pass :c:data:`PY_BIG_ENDIAN` | |||
There was a problem hiding this comment.
So if your platform is little-endian, then passing PY_BIG_ENDIAN uses a little-endian format? That seems confusing.
There was a problem hiding this comment.
PY_BIG_ENDIAN is 1 on big endian platform, and 0 on little endian platform.
int.to_bytes() uses the native endian by default (if the byte_order parameter is not set). Maybe we could accept -1 to mean "use native endian"?
There was a problem hiding this comment.
int.to_bytes() uses the native endian by default
It uses big-endian by default.
There was a problem hiding this comment.
Oops. You're right. I now recall a long discussion about the default :-)
There was a problem hiding this comment.
That seems confusing.
Agreed, but it's primarily a problem with the naming of PY_BIG_ENDIAN, which would perhaps be better spelled as something like PY_PLATFORM_ENDIAN_IS_BIG_ENDIAN.
But usage of PY_BIG_ENDIAN is at least a little bit problematic, since there's nothing anywhere in C that guarantees that integer types and float types will use the same endianness (or even that float types have to follow one of big-endian or little-endian at all).
Maybe we could accept -1 to mean "use native endian"?
I'd suggest leaving it as-is - it's easy enough to pass PY_BIG_ENDIAN.
There was a problem hiding this comment.
I proposed a different wording for the documentation: PR #31866. Is it better?
There was a problem hiding this comment.
Changes LGTM. I do agree with @JelleZijlstra that it's potentially confusing, but I don't see a solution to that other than renaming PY_BIG_ENDIAN.
|
I merged the PR #31866 instead. |
https://bugs.python.org/issue46906