Skip to content

Conversation

@F18-Maverick
Copy link
Contributor

@F18-Maverick F18-Maverick commented Nov 4, 2025

@F18-Maverick

This comment was marked as outdated.

Copy link
Contributor

@skirpichev skirpichev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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

?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, I think NaN type is better.

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`` ``p+7``), zero if you
format (exponent last, at ``p+1``, ``p+3``, or ``p+6`` and ``p+7``), zero if you
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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

@skirpichev skirpichev added needs backport to 3.13 bugs and security fixes needs backport to 3.14 bugs and security fixes labels Nov 10, 2025
@F18-Maverick
Copy link
Contributor Author

And you said that there is a merge conflict. So is there anything I can do?

@skirpichev
Copy link
Contributor

You can resolve merge conflict.

@F18-Maverick
Copy link
Contributor Author

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?

@F18-Maverick
Copy link
Contributor Author

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, no. Now you reverted back change from #141179. Plese undo this.

Corrected the description of NaN type preservation on IEEE platforms.
@F18-Maverick
Copy link
Contributor Author

Okay, I just reverted back the change and change NaNs type to NaN type.

@F18-Maverick
Copy link
Contributor Author

Emm.. So is it the time to merge my PR? I think there is no problem right?

@skirpichev
Copy link
Contributor

PR must be approved and merged by core developer.

@F18-Maverick
Copy link
Contributor Author

Yes, I know that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

awaiting core review docs Documentation in the Doc dir needs backport to 3.13 bugs and security fixes needs backport to 3.14 bugs and security fixes skip issue skip news

Projects

Status: Todo

Development

Successfully merging this pull request may close these issues.

2 participants