[issue45995] string formatting: normalize negative zero

Mark Dickinson added the comment: I forgot to update here: > PEP at https://github.com/python/peps/pull/2295 For the record, PEP 682 has been accepted. -- ___ Python tracker ___

[issue45995] string formatting: normalize negative zero

John Belmonte added the comment: PEP at https://github.com/python/peps/pull/2295 -- ___ Python tracker ___ ___ Python-bugs-list mai

[issue45995] string formatting: normalize negative zero

John Belmonte added the comment: Thank you Mark and Eric. > I'll note that the paper is proposing a 'z' modifier to the sign, so I guess > for us that would translate to: [sign[optional-z]] instead of just sign. I'd > have to noodle through the differences between that the proposed [sign][~

[issue45995] string formatting: normalize negative zero

Eric V. Smith added the comment: Wow, thanks, Mark! I'm generally in favor. The selling points to me are that it needs to happen post-rounding, and the C++ discussion. It would be better if this were already accepted in C++. I'll note that the paper is proposing a 'z' modifier to the sign,

[issue45995] string formatting: normalize negative zero

Mark Dickinson added the comment: [John] > Mark, would you give it a review this month? Apologies; my holiday-break free time was nobbled from unexpected quarters. I can't promise to find time this month, but I can promise to try. I did at least skim through the PR, and while there are stil

[issue45995] string formatting: normalize negative zero

John Belmonte added the comment: Mark, would you give it a review this month? (PR has been marked stale.) -- ___ Python tracker ___ __

[issue45995] string formatting: normalize negative zero

Mark Dickinson added the comment: Thanks, John. I should have time to review within the next week or so. -- ___ Python tracker ___

[issue45995] string formatting: normalize negative zero

Change by Mark Dickinson : -- assignee: -> mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: ht

[issue45995] string formatting: normalize negative zero

John Belmonte added the comment: implemented float and Decimal-- PR is ready for review -- ___ Python tracker ___ ___ Python-bugs-l

[issue45995] string formatting: normalize negative zero

John Belmonte added the comment: potential short-term solution for Decimal: if negative zero option is set and sign is negative: pre-round into a temp using mpd_qrescale() if mpd_iszero(temp): change sign to positive -- ___

[issue45995] string formatting: normalize negative zero

John Belmonte added the comment: > For Decimal, we'd need to "own" the string formatting, taking that > responsibility away from mpdecimal, but there are already other reasons to do > that. After some digging, I believe this is the background on forking pieces of mpdecimal (and why the exis

[issue45995] string formatting: normalize negative zero

Change by John Belmonte : -- keywords: +patch nosy: +jbelmonte nosy_count: 5.0 -> 6.0 pull_requests: +28274 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30049 ___ Python tracker __

[issue45995] string formatting: normalize negative zero

John Belmonte added the comment: I'll share a draft PR soon (excluding Decimal), so far it's still looking straightforward. > Maybe old versions would correctly ignore the new bit being set. That's one of the benefits of using bit flags in an ABI: backward-compatible extensibility. (An imp

[issue45995] string formatting: normalize negative zero

Eric V. Smith added the comment: PyOS_double_to_string is part of the stable ABI. I don't recall if we're allowed to add new bitfield flags to a stable ABI function. We'd use a new Py_DTSF_NORMALIZE_NEGATIVE_0 flag for this feature. I suspect we can't add a flag, due to comparability reasons

[issue45995] string formatting: normalize negative zero

John Belmonte added the comment: I see now. PyOS_double_to_string() could gain the extra flag to coerce negative zero but, out of the three formatting methods, only format() and f-string would use the flag. -- ___ Python tracker

[issue45995] string formatting: normalize negative zero

Eric V. Smith added the comment: %-formatting already doesn't support some formats that float.__format__ does, for example ','. So I agree we shouldn't modify %-formatting. I don't have much of an opinion on whether changing __format__ is a good idea or not. --

[issue45995] string formatting: normalize negative zero

Steven D'Aprano added the comment: Sorry John, I don't understand your comment about "treating %-formatting specifically". Isn't the point here not to change %-formatting at all? -- ___ Python tracker _

[issue45995] string formatting: normalize negative zero

John Belmonte added the comment: > changing %-formatting doesn't seem viable I'm concerned about treating %-formatting specially. As far as float/complex, the logical and efficient place to put this change seems to be PyOS_double_to_string(), which affects all three formatting options. For

[issue45995] string formatting: normalize negative zero

Serhiy Storchaka added the comment: Well, it makes sense for negative zero produced by rounding. But if we add a special support for this case, it would be useful to have some control on the type of rounding. Currently floats are rounded to the nearest decimal number, but in some cases it wo

[issue45995] string formatting: normalize negative zero

Mark Dickinson added the comment: I'd support having this functionality available for `format` and for f-strings. (As Steven says, changing %-formatting doesn't seem viable.) It really _is_ awkward to do this in any other way, and I'm reliably informed that normal people don't expect to see

[issue45995] string formatting: normalize negative zero

Change by Mark Dickinson : -- nosy: +eric.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.

[issue45995] string formatting: normalize negative zero

John Belmonte added the comment: Here is the same proposal made for C++ `std::format`: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1496r2.pdf It makes fair arguments for the feature's use, and explains why the problem is hard to work around. It was withdrawn by the author for

[issue45995] string formatting: normalize negative zero

Steven D'Aprano added the comment: It was decided long ago that % formatting would not be enhanced with new features. I think that it is supposed to match the standard C formatting codes, and nothing else. So this is unlikely to be approved for % formatting. It *might* be approved for the f

[issue45995] string formatting: normalize negative zero

John Belmonte added the comment: > To normalize negative 0.0 to 0.0 you can just add 0.0. yes, I'm aware-- see "implementation" in the original post > there is no need to change all formatting specifications For adding 0 to work, it must be done after the rounding. That means if you want m

[issue45995] string formatting: normalize negative zero

Serhiy Storchaka added the comment: To normalize negative 0.0 to 0.0 you can just add 0.0. It will work with any method of converting floats to string, there is no need to change all formatting specifications. >>> x = -0.0 >>> x -0.0 >>> x + 0.0 0.0 -- nosy: +mark.dickinson, serhiy.

[issue45995] string formatting: normalize negative zero

New submission from John Belmonte : proposal: add a string formatting option to normalize negative 0 values to 0 use case: rounded display of a float that is nominally 0, where the distraction of a flashing minus sign from minute changes around 0 is unwanted example: >>> '%~5.1f' % -.1 '