bpo-39096: Improve description of 'e', 'f' and 'g' presentation types #23537
Conversation
There was a problem hiding this comment.
This looks great, @mdickinson. I just have a few small comments, feel free to ignore them.
Doc/library/string.rst
Outdated
| | | precision given, uses a precision of ``6`` digits after | | ||
| | | the decimal point for :class:`float`, and uses a | | ||
| | | precision large enough to show all coefficient digits | | ||
| | | for :class:`~decimal.Decimal`. | |
There was a problem hiding this comment.
Same comment about p == 0 and omitting the decimal point.
Doc/library/string.rst
Outdated
| | | significant digits. With no precision given, uses a | | ||
| | | precision of ``6`` digits after the decimal point for | | ||
| | | :class:`float`, and shows all coefficient digits | | ||
| | | for :class:`~decimal.Decimal`. | |
There was a problem hiding this comment.
Should you mention here that if p == 0, the decimal point is omitted unless # is used?
Also: is it generally understood that for Decimal, "all coefficient digits" includes the trailing zeros? Again, I can see people reporting it as an issue until they're told that the trailing zeros are significant.
There was a problem hiding this comment.
Yep, my original draft for this text had an "(including trailing zeros)"; I can put it back. I took it out partly because the text seemed to be getting too long, and partly out of a fear that it might cause more confusion rather than less and lead to a need to explain exactly what's meant by "trailing zeros". And this doesn't seem like the right place for that explanation.
So ... not sure.
There was a problem hiding this comment.
And yes, I'll update for the missing decimal point, both here and for the f text.
There was a problem hiding this comment.
You're probably right about leaving out the "trailing zeros". There's a lot here already.
There was a problem hiding this comment.
if
p == 0, the decimal point is omitted unless#is used
Argh. The reality is messy. Decimal apparently still doesn't support the # alternate format. (There ought to be an issue open about this somewhere.)
There's a paragraph below the table about the inclusion or not of the decimal point. I'll see if I can update that to reflect reality.
There was a problem hiding this comment.
…t, except in alternate form
|
Updated for review comments. The table still leaves it unclear that the alternate form is not supported for |
|
@mdickinson: Please replace |
|
Thanks @mdickinson for the PR 🌮🎉.. I'm working now to backport this PR to: 3.8, 3.9. |
…pythonGH-23537) * Improve description of 'e', 'f' and 'g' presentation types * Drop the 'E' from Scientific 'E' notation; remove >= 0 qualifications * Fix false statement that the alternate form is valid for Decimal * Nitpick: remove the Harvard/Oxford comma * Add note that the decimal point is also removed if no digits follow it, except in alternate form (cherry picked from commit c642374) Co-authored-by: Mark Dickinson <mdickinson@enthought.com>
|
GH-23550 is a backport of this pull request to the 3.9 branch. |
…pythonGH-23537) * Improve description of 'e', 'f' and 'g' presentation types * Drop the 'E' from Scientific 'E' notation; remove >= 0 qualifications * Fix false statement that the alternate form is valid for Decimal * Nitpick: remove the Harvard/Oxford comma * Add note that the decimal point is also removed if no digits follow it, except in alternate form (cherry picked from commit c642374) Co-authored-by: Mark Dickinson <mdickinson@enthought.com>
|
GH-23551 is a backport of this pull request to the 3.8 branch. |
…GH-23537) (GH-23550) * Improve description of 'e', 'f' and 'g' presentation types * Drop the 'E' from Scientific 'E' notation; remove >= 0 qualifications * Fix false statement that the alternate form is valid for Decimal * Nitpick: remove the Harvard/Oxford comma * Add note that the decimal point is also removed if no digits follow it, except in alternate form (cherry picked from commit c642374) Co-authored-by: Mark Dickinson <mdickinson@enthought.com> Co-authored-by: Mark Dickinson <mdickinson@enthought.com>
…GH-23537) (GH-23551) * Improve description of 'e', 'f' and 'g' presentation types * Drop the 'E' from Scientific 'E' notation; remove >= 0 qualifications * Fix false statement that the alternate form is valid for Decimal * Nitpick: remove the Harvard/Oxford comma * Add note that the decimal point is also removed if no digits follow it, except in alternate form (cherry picked from commit c642374) Co-authored-by: Mark Dickinson <mdickinson@enthought.com> Co-authored-by: Mark Dickinson <mdickinson@enthought.com>
…python#23537) * Improve description of 'e', 'f' and 'g' presentation types * Drop the 'E' from Scientific 'E' notation; remove >= 0 qualifications * Fix false statement that the alternate form is valid for Decimal * Nitpick: remove the Harvard/Oxford comma * Add note that the decimal point is also removed if no digits follow it, except in alternate form
The table of presentation types in the "Format specification mini-language" section of the library documentation tries to cover both
Decimalandfloat, but is inaccurate in a number of ways forDecimal.This PR fixes one particular part of that inaccuracy - the description of the default precision - and makes some other cleanups and consistency fixes along the way. In more detail:
I'm aiming for an incremental improvement here rather than a complete, perfectly-accurate description.
A wider issue is whether we should be attempting to document the rules for
Decimalat all in this table, or whether we should simply document these as the rules forfloat, and move the description forDecimalelsewhere. But I think that ship has sailed already.@ericvsmith : Any interest in reviewing?
https://bugs.python.org/issue39096