Skip to content

bpo-28415: Note 0 conversion different between Python and C #885

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 6 commits into from
Apr 27, 2017
Merged

bpo-28415: Note 0 conversion different between Python and C #885

merged 6 commits into from
Apr 27, 2017

Conversation

louisom
Copy link
Contributor

@louisom louisom commented Mar 29, 2017

No description provided.

@mention-bot
Copy link

@grapherd, thanks for your PR! By analyzing the history of the files in this pull request, we identified @birkenfeld, @serhiy-storchaka and @benjaminp to be potential reviewers.

Copy link
Member

@zhangyangyu zhangyangyu left a comment

Choose a reason for hiding this comment

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

I think instead of a .. note::, it's better to follow the style of the table in https://docs.python.org/3/library/stdtypes.html#printf-style-string-formatting since we may find more exceptions in future. And I think the examples are not needed.

@zhangyangyu zhangyangyu added docs Documentation in the Doc dir cherry-pick for 3.5 and removed cherry-pick for 3.5 labels Mar 29, 2017
@serhiy-storchaka
Copy link
Member

Too much words for minor difference.

@louisom
Copy link
Contributor Author

louisom commented Mar 29, 2017

@zhangyangyu @serhiy-storchaka After reference the description from cpp - printf, simplify the note about it.

@zhangyangyu
Copy link
Member

zhangyangyu commented Mar 29, 2017

Actually I prefer the previous wording:

the '0' conversion flag IS NOT ignored when a precision is given for 'd', 'i', 'o', 'u', 'x' and 'X' conversion types.

It's more direct to me and the current wording gives a feeling that the precision won't take effects at all. :-(
And I am not sure this deserves a highlight.

@terryjreedy
Copy link
Member

terryjreedy commented Mar 30, 2017

See comment on https://bugs.python.org/issue28415 for minimal and terse alternatives. Build error will disappear with either suggestion.

Copy link
Member

@terryjreedy terryjreedy left a comment

Choose a reason for hiding this comment

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

See link to issue in comment

@rhettinger
Copy link
Contributor

Just adding the two notes will suffice. I don't think readers are helped at all by changing "exactly" to "nearly" over such a minor distinction. The word "nearly" creates an unnecessary sense of risk and uncertainty in the minds of readers. Also, I think this is so unimportant that it shouldn't be backported.

Copy link
Member

@terryjreedy terryjreedy left a comment

Choose a reason for hiding this comment

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

The proposed addition is not proper English. I give a different version on the issue. I also think 'exactly' should just be removed when not exactly true, but will not push for that.

@@ -72,28 +72,28 @@ called with a non-bytes parameter.
| :attr:`%c` | int | A single byte, |
| | | represented as a C int. |
+-------------------+---------------+--------------------------------+
| :attr:`%d` | int | Exactly equivalent to |
| :attr:`%d` | int | Nearly equivalent to |
| | | ``printf("%d")``. |
Copy link
Member

Choose a reason for hiding this comment

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

Please add a reference to the note, like (1).

I would prefer to remove Nearly/Exactly. I don't think that the subtle difference is major enough to justify a "Nearly".

Copy link
Member

Choose a reason for hiding this comment

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

So we agree dropping 'exactly' when not exactly true.

@@ -451,43 +451,43 @@ APIs:
| :attr:`%c` | int | A single character, |
| | | represented as a C int. |
+-------------------+---------------------+--------------------------------+
| :attr:`%d` | int | Exactly equivalent to |
| :attr:`%d` | int | Nearly equivalent to |
Copy link
Member

Choose a reason for hiding this comment

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

Ditto

@louisom
Copy link
Contributor Author

louisom commented Apr 26, 2017

@terryjreedy, @Haypo, @zhangyangyu, could you help for review the latest addressed?
Thanks!

@terryjreedy
Copy link
Member

Replacing the original 'Exactly' with a note marker looks good to me. I cannot apply patch to test generated html for correct formatting, but assuming you have, I approve net result.

@louisom
Copy link
Contributor Author

louisom commented Apr 27, 2017

I put down the unicode footnote under the original note block

@zhangyangyu zhangyangyu merged commit 88c38b3 into python:master Apr 27, 2017
@zhangyangyu
Copy link
Member

zhangyangyu commented Apr 27, 2017

Thanks @lulouie ! This style looks good and is actually what I mean at first.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs Documentation in the Doc dir
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants