[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

[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 breamore...@yahoo.co.uk: -- nosy: -BreamoreBoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6871 ___ ___

[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 rep...@bugs.python.org http://bugs.python.org/issue6871

[issue6871] decimal.py: more format issues

2010-02-22 Thread Eric Smith
Eric Smith e...@trueblade.com 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

2010-02-22 Thread Stefan Krah
Stefan Krah stefan-use...@bytereef.org 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]

[issue6871] decimal.py: more format issues

2010-02-22 Thread Stefan Krah
Stefan Krah stefan-use...@bytereef.org 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. --

[issue6871] decimal.py: more format issues

2010-02-22 Thread Eric Smith
Eric Smith e...@trueblade.com 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

[issue6871] decimal.py: more format issues

2009-09-13 Thread Mark Dickinson
Mark Dickinson dicki...@gmail.com 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 rep...@bugs.python.org

[issue6871] decimal.py: more format issues

2009-09-13 Thread Mark Dickinson
Mark Dickinson dicki...@gmail.com added the comment: From the current trunk: format(float('1e88'), '120') '1e+88111' [64734 refs] format(float('1e88'), '020') '0001e+88' [64734 refs] -- ___ Python tracker

[issue6871] decimal.py: more format issues

2009-09-13 Thread Eric Smith
Eric Smith e...@trueblade.com 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-10 Thread Stefan Krah
Stefan Krah stefan-use...@bytereef.org added the comment: Issue 3 is nonsense, '-' means left-justified in C. Sorry. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6871 ___

[issue6871] decimal.py: more format issues

2009-09-09 Thread Stefan Krah
New submission from Stefan Krah stefan-use...@bytereef.org: 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),

[issue6871] decimal.py: more format issues

2009-09-09 Thread Eric Smith
Eric Smith e...@trueblade.com 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

[issue6871] decimal.py: more format issues

2009-09-09 Thread Eric Smith
Eric Smith e...@trueblade.com added the comment: Also, see issue 4482 for a discussion of float formatting for nan and inf. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6871 ___

[issue6871] decimal.py: more format issues

2009-09-09 Thread Mark Dickinson
Mark Dickinson dicki...@gmail.com 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 Stefan Krah
Stefan Krah stefan-use...@bytereef.org 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