Uh oh!
There was an error while loading. Please reload this page.
Docs: fix a form error and a grammatical error in float.rst - #140989
Conversation
This comment was marked as outdated.
This comment was marked as outdated.
skirpichev
left a comment
There was a problem hiding this comment.
And there is a merge conflict.
| exception. | ||
| Note that NaNs type may not be preserved on IEEE platforms (silent NaN become | ||
| Note that NaN types may not be preserved on IEEE platforms (silent NaN become |
There was a problem hiding this comment.
| Note that NaN types may not be preserved on IEEE platforms (silent NaN become | |
| Note that NaN type may not be preserved on IEEE platforms (silent NaN become |
?
There was a problem hiding this comment.
Okay, I think NaN type is better.
Uh oh!
There was an error while loading. Please reload this page.
F18-Maverick
commented
Nov 10, 2025
And you said that there is a merge conflict. So is there anything I can do? |
skirpichev
commented
Nov 10, 2025
You can resolve merge conflict. |
F18-Maverick
commented
Nov 10, 2025
Sorry, but how can I resolve it? I mean this is the first time I meet the merge conflict problem, and I just checked my python repo branches list, there is no problem. So do you mean I can't fix two issues in one PR? |
skirpichev
commented
Nov 10, 2025
You can just push "Resolve conflict" button in your pr: Or do it from the command-line: |
F18-Maverick
commented
Nov 10, 2025
Okay, so what about now? |
| Note that NaNs type may not be preserved on IEEE platforms (signaling NaN become | ||
| quiet NaN), for example on x86 systems in 32-bit mode. | ||
| Note that NaN types may not be preserved on IEEE platforms (silent NaN become |
There was a problem hiding this comment.
Sorry, no. Now you reverted back change from #141179. Plese undo this.
Corrected the description of NaN type preservation on IEEE platforms.
F18-Maverick
commented
Nov 10, 2025
Okay, I just reverted back the change and change NaNs type to NaN type. |
F18-Maverick
commented
Nov 12, 2025
Emm.. So is it the time to merge my PR? I think there is no problem right? |
skirpichev
commented
Nov 12, 2025
PR must be approved and merged by core developer. |
F18-Maverick
commented
Nov 12, 2025
Yes, I know that. |
F18-Maverick
commented
Nov 28, 2025
I'm sorry, but it's been quite a while since I submitted it, and I believe it's ready to be merged. I would greatly appreciate it if you could remind a core developer to take a look and merge the PR. Thank you! |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Co-authored-by: Stan Ulbrych <89152624+StanFromIreland@users.noreply.github.com>
Co-authored-by: Sergey B Kirpichev <skirpichev@gmail.com>
| The pack routines write 2, 4 or 8 bytes, starting at *p*. *le* is an | ||
| :c:expr:`int` argument, non-zero if you want the bytes string in little-endian | ||
| format (exponent last, at ``p+1``, ``p+3``, or ``p+6`` and ``p+7``), zero if you | ||
| format (exponent last, at ``p+1``, ``p+3``, or ``p+6``, ``p+7``), zero if you |
Thanks @F18-Maverick for the PR, and @kumaraditya303 for merging it 🌮🎉.. I'm working now to backport this PR to: 3.13, 3.14. |
Sorry, @F18-Maverick and @kumaraditya303, I could not cleanly backport this to |
GH-146012 is a backport of this pull request to the 3.14 branch. |
serhiy-storchaka
commented
Jul 15, 2026
Please don't forget about backports. |
AjobK
commented
Jul 19, 2026
As this documentation did not exist yet in version 3.13, it makes no sense to backport just this typo. Instead, if we would like to do this we should apply the entire section of documentation, which I believe falls out of scope. |
StanFromIreland
commented
Jul 19, 2026
Thanks for investigating! |
📚 Documentation preview 📚: https://cpython-previews--140989.org.readthedocs.build/