[issue6871] decimal.py: more format issues

2021-06-19 Thread Eric V. Smith
Eric V. Smith added the comment: Thanks, Irit. I'm closing this as "won't fix". -- resolution: out of date -> wont fix stage: -> resolved status: open -> closed ___ Python tracker __

[issue6871] decimal.py: more format issues

2021-06-19 Thread Irit Katriel
Irit Katriel added the comment: No just trying to sort out the backlog. -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue6871] decimal.py: more format issues

2021-06-19 Thread Eric V. Smith
Eric V. Smith added the comment: I tend to agree with Mark: any change would be disruptive, and it doesn't seem to be causing any real problem. Irit: did you come across this because it's causing a problem somewhere? -- ___ Python tracker

[issue6871] decimal.py: more format issues

2021-06-19 Thread Mark Dickinson
Mark Dickinson added the comment: Eric: any thoughts on this? It's looking like a "won't fix" to me. Regardless of what we think the "right" thing to do is, making the float behaviour stricter would be a backwards compatibility break, and relaxing the Decimal behaviour involves either diver

[issue6871] decimal.py: more format issues

2021-06-18 Thread Irit Katriel
Irit Katriel added the comment: Issue #2 still exists in 3.11: >>> format(float(123), "00") '123.0' >>> format(Decimal(123), "00") Traceback (most recent call last): File "", line 1, in ValueError: invalid format string -- nosy: +iritkatriel versions: +Python 3.11

[issue6871] decimal.py: more format issues

2014-02-03 Thread Mark Lawrence
Changes by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue6871] decimal.py: more format issues

2013-05-25 Thread Mark Lawrence
Mark Lawrence added the comment: If I'm reading this correctly only issue 2 is outstanding. Opinions please gentlemen. -- nosy: +BreamoreBoy ___ Python tracker ___ _

[issue6871] decimal.py: more format issues

2010-02-22 Thread Eric Smith
Eric Smith added the comment: [If the status is pending, any comment turns it back to open, by design.] I'd rather float.__format__ agree with %-formatting for floats than with anything else. >>> '%+08.4f' % float('nan') '+nan' >>> "%00f" % float('123') '123.00' (Not sure about the p

[issue6871] decimal.py: more format issues

2010-02-22 Thread Stefan Krah
Stefan Krah added the comment: [The tracker apparently set the status to 'open' without my intervention.] To sum up what I said earlier about #1 and #2, I think that the C standard and gcc's warning behavior support the way of Decimal. -- ___ Python

[issue6871] decimal.py: more format issues

2010-02-22 Thread Stefan Krah
Stefan Krah added the comment: I couldn't find other issues where #1 and #2 are addressed. This is from py3k: #1: >>> format(float('nan'), '+08.4') '+nan' [70141 refs] >>> format(Decimal('nan'), '+08.4') '+NaN' #2:>>> format(float(123), "00") '123.0' [70141 refs] >>> format(Decimal(

[issue6871] decimal.py: more format issues

2010-02-22 Thread Eric Smith
Eric Smith added the comment: I think there are no remaining issues here that don't have their own issue. I'm going to close this unless one of you think otherwise. -- assignee: -> eric.smith resolution: -> out of date status: open -> pending type: -> behavior _

[issue6871] decimal.py: more format issues

2009-09-13 Thread Eric Smith
Eric Smith added the comment: Created issue 6902 to handle #4. The others will need to be broken out into their own issues if we want to fix them. I can't keep track of multiple issues in one bug report. -- ___ Python tracker

[issue6871] decimal.py: more format issues

2009-09-13 Thread Eric Smith
Eric Smith added the comment: The '0' fill character is forcing '=' alignment (per the PEP). This looks like a bug to me, since it should use the specified alignment. This is not a float-only problem, it applies to the other built-in types as well: >>> format(2, '0<20') '0002' >

[issue6871] decimal.py: more format issues

2009-09-13 Thread Mark Dickinson
Mark Dickinson added the comment: >From the current trunk: >>> format(float('1e88'), '1<20') '1e+88111' [64734 refs] >>> format(float('1e88'), '0<20') '0001e+88' [64734 refs] -- ___ Python tracker

[issue6871] decimal.py: more format issues

2009-09-13 Thread Mark Dickinson
Mark Dickinson added the comment: I think issue #4 is a bug in float formatting: I don't think it makes sense to change alignment just because the fill character happens to be '0'. -- ___ Python tracker

[issue6871] decimal.py: more format issues

2009-09-10 Thread Stefan Krah
Stefan Krah added the comment: Issue 3 is nonsense, '-' means left-justified in C. Sorry. -- ___ Python tracker ___ ___ Python-bugs-li

[issue6871] decimal.py: more format issues

2009-09-09 Thread Stefan Krah
Stefan Krah added the comment: Issue 1: I would definitely keep the spelling in decimal, my concern was only the padding. The C standard agrees with Mark's view: "Leading zeros (following any indication of sign or base) are used to pad to the field width rather than performing space padding,

[issue6871] decimal.py: more format issues

2009-09-09 Thread Mark Dickinson
Mark Dickinson added the comment: Issue #1: In both trunk and py3k I get: >>> from decimal import Decimal >>> format(Decimal('nan'), '+08.4') '+NaN' >>> format(float('nan'), '+08.4') '+nan' >>> format(Decimal('inf'), '+012.4') ' +Infinity' >>> format(float('inf'), '+012.4') '+

[issue6871] decimal.py: more format issues

2009-09-09 Thread Eric Smith
Eric Smith added the comment: Also, see issue 4482 for a discussion of float formatting for nan and inf. -- ___ Python tracker ___ ___

[issue6871] decimal.py: more format issues

2009-09-09 Thread Eric Smith
Eric Smith added the comment: For #1 for floats, 2.6 is in error. This has been fixed in 2.7 (trunk). For #2, I think float is correct. The PEP says the specifier is: [[fill]align][sign][#][0][minimumwidth][.precision][type] so '00' is parsed as minimumwidth=0 with zero-padding specified.

[issue6871] decimal.py: more format issues

2009-09-09 Thread Stefan Krah
New submission from Stefan Krah : Hi, I've two more issues where format behavior should probably be identical: 1: (version 2.6 vs. 3.1): Version 2.6: >>> format(Decimal("NaN"), "+08.4") '+NaN' >>> format(float("NaN"), "+08.4") '+00.0nan' Version 3.1: >>> format(Decimal("NaN"), "+08.4") '+