Skip to content

Conversation

@F18-Maverick
Copy link
Contributor

@F18-MaverickF18-Maverick commented Nov 4, 2025

@F18-Maverick

This comment was marked as outdated.

Copy link
Member

@skirpichevskirpichev 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
Member

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
ContributorAuthor

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
Member

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

@skirpichevskirpichev 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
ContributorAuthor

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

@skirpichev
Copy link
Member

You can resolve merge conflict.

@F18-Maverick
Copy link
ContributorAuthor

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
ContributorAuthor

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
Member

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
ContributorAuthor

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

@F18-Maverick
Copy link
ContributorAuthor

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

@skirpichev
Copy link
Member

PR must be approved and merged by core developer.

@F18-Maverick
Copy link
ContributorAuthor

Yes, I know that.

@F18-Maverick
Copy link
ContributorAuthor

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!

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

Labels

awaiting core reviewdocsDocumentation in the Doc dirneeds backport to 3.13bugs and security fixesneeds backport to 3.14bugs and security fixesskip issueskip news

Projects

Status: Todo

Development

Successfully merging this pull request may close these issues.

2 participants

@F18-Maverick@skirpichev