[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Mark Dickinson added the comment: > Yes, this is a separate issue. Thanks. See issue 5920. -- ___ Python tracker ___ ___ Python-bugs

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Eric Smith added the comment: > Hmm. That also seems wrong to me. So I guess it's a suggestion > for float as well, which means it's not specific to this issue. > Should I open a separate feature request? Yes, this is a separate issue. It comes from PEP 3101's specification of "like 'g' but

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Mark Dickinson added the comment: Hmm. That also seems wrong to me. So I guess it's a suggestion for float as well, which means it's not specific to this issue. Should I open a separate feature request? -- ___ Python tracker

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Eric Smith added the comment: Is this suggestion for all types, or just complex? Because float has the same issue. >>> format(pi, '') '3.14159265359' [38243 refs] >>> format(pi, '>') '3.14159' -- ___ Python tracker

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Mark Dickinson added the comment: One comment on the new complex formatting. I now get (in py3k) >>> from math import pi, e >>> format(complex(pi,e), '<') '(3.14159+2.71828j)' >>> format(complex(pi,e), '') '(3.14159265359+2.71828182846j)' I understand why this is happening, but again I think

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Eric Smith added the comment: Thanks, Mark. I'm not so worried about the code, but more so the tests. As far as the code goes, it's really a combination of float and string formatting. I copied the float formatting and refactored the string formatting so I could reuse it. But of course, anothe

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Mark Dickinson added the comment: I haven't done as thorough a review as I'd like, but both patches look good to me. I recommend applying them. -- ___ Python tracker ___ ___

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Mark Dickinson added the comment: With these patches, all tests pass for me both for py3k and trunk. -- ___ Python tracker ___ ___ Pyt

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Changes by Eric Smith : Removed file: http://bugs.python.org/file13805/issue-1588-2-py3k.patch ___ Python tracker ___ ___ Python-bugs-list mail

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Changes by Eric Smith : Removed file: http://bugs.python.org/file13802/issue-1588-1-py3k.patch ___ Python tracker ___ ___ Python-bugs-list mail

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Changes by Eric Smith : Removed file: http://bugs.python.org/file13801/issue-1588-0.patch ___ Python tracker ___ ___ Python-bugs-list mailing l

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Changes by Eric Smith : Added file: http://bugs.python.org/file13808/issue-1588-py3k.patch ___ Python tracker ___ ___ Python-bugs-list mailing

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Eric Smith added the comment: I think these patches are complete. One for py3k, one for trunk. If no complaints, I'll apply them before this weekend's py3k beta. -- Added file: http://bugs.python.org/file13807/issue-1588-trunk.patch ___ Python tracke

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Eric Smith added the comment: I also propose to disallow the '=' alignment flag. It means put the padding between the sign and the digits, and since there are 2 signs, it's not clear what this would mean. Remember, by using .real and .imag, you can achieve this level of control in the formattin

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Eric Smith added the comment: This is a patch against py3k, including tests in test_complex.py. It should deal with the padding, but let me know. -- stage: test needed -> patch review Added file: http://bugs.python.org/file13805/issue-1588-2-py3k.patch _

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Eric Smith added the comment: ... > Is this intentional? I was expecting to get strings of length 20, > with the substring '(123+4j)' positioned either in the middle > or on the left or right. No, not intentional. I'll fix it and add some tests. Thanks. -- __

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Mark Dickinson added the comment: With your patch, I'm getting quite strange results when using alignment specifiers: >>> z = 123+4j >>> format(z, '=20') '( 123+ 4j)' >>> format(z, '^20') '(123 +4 j)' >>> format(z, '<20') '(123

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Eric Smith added the comment: Here's a patch against py3k, with one slight change with non-empty presentation types. -- Added file: http://bugs.python.org/file13802/issue-1588-1-py3k.patch ___ Python tracker __

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Eric Smith added the comment: Mark Dickinson wrote: > The trailing zeros thing is heavily bound up with issue 5858, of course; > I think we need a decision on that, one way or the other. One problem > is that I'm only proposing the issue 5858 change for py3k, not trunk. I don't have a problem

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Mark Dickinson added the comment: I'll take a look. The trailing zeros thing is heavily bound up with issue 5858, of course; I think we need a decision on that, one way or the other. One problem is that I'm only proposing the issue 5858 change for py3k, not trunk. -- stage: patch revi

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Eric Smith added the comment: See the attached patch. Comments welcome. I'm not sure I'm doing the right thing with 'g' and appending zeros: >>> format(3+4j, '.2') '(3+4j)' >>> format(3+4j, '.2g') '3.0+4.0j' >>> format(3+0j, '.2') '(3+0j)' >>> format(3+0j, '.2g') '3.0+0.0j' >>> format(1j, '.2')

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Eric Smith added the comment: Mark Dickinson wrote: >> Although I guess if we wanted to, we could say that the empty >> presentation type is equivalent to 'g', but gives you parens. > > This works for me. Me, too. > [about suppressing real zeros...] >> Again, we could say that the empty pres

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Mark Dickinson added the comment: > Complex would be the first one. But that doesn't really bother me. It bothers me a little. I see '' as a special case of the empty presentation type, even if that's not what a strict reading of PEP 3101 says, so I expect '', '>' '<20' all to format the numbe

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Eric Smith added the comment: Mark Dickinson wrote: > (1) What about parentheses? The current complex repr and str have > parentheses in them, for reasons that I still don't really understand. > > I'd suggest leaving them out altogether; except that I have > the impression (perhaps wrongly) th

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Mark Dickinson added the comment: Two things that haven't come up so far: (1) What about parentheses? The current complex repr and str have parentheses in them, for reasons that I still don't really understand. I'd suggest leaving them out altogether; except that I have the impression (perhap

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Mark Dickinson added the comment: > I'm also going to disallow the '%' format code. Sounds good to me. > I don't think it makes any sense to convert a complex number to a > percentage. Well, I think it's clear what the numbers would be (just scale both real and imaginary parts by 100 before u

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Eric Smith added the comment: I'm also going to disallow the '%' format code. I don't think it makes any sense to convert a complex number to a percentage. -- ___ Python tracker

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Eric Smith added the comment: > More specifically, how about allowing widths, and the > '<', '>' and '^' alignment specifiers, but not '=', or > '0' for zero-padding. That sounds correct. > I suppose that thousands separators should be permitted > here too? Though it's difficult to imagine an

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Mark Dickinson added the comment: > I think a ValueError would be best. That way if we decide to give it > some meaning in the future, we know it won't change any working code. Agreed. It also fits with the way that other non-numeric types seem to behave, as in: >>> format("boris", "030s") T

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Eric Smith added the comment: > This sounds good to me. I assume a '+' would still affect > the sign of the real part? Forgot to reply to this part. Yes, a '+', '-', or ' ' would still affect the real part, but the imaginary part would always use '+'. --

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Mark Dickinson added the comment: More specifically, how about allowing widths, and the '<', '>' and '^' alignment specifiers, but not '=', or '0' for zero-padding. I suppose that thousands separators should be permitted here too? Though it's difficult to imagine anyone actually using them. I

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Eric Smith added the comment: > I don't see any problem with dealing with width, alignment > and padding with a user-specified fill character; I think we > should keep these if possible. It's just zero padding where > it's not clear what should happen. You're correct. It's just zero padding t

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Mark Dickinson added the comment: > How about this: > - we have a single specifier with the same format as floats > - we force the sign on the imaginary part to be '+', no >matter what was specified > - we add a 'j' after the imaginary part This sounds good to me. I assume a '+' would sti

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Changes by Eric Smith : -- assignee: -> eric.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Eric Smith added the comment: Mark Dickinson wrote: >> What should the format specifier mini-language for complex numbers look >> like? >> Should it look like the existing mini-language for floats, but have >> the format specified twice, with some sort of delimiter? > > This sounds clumsy to me

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Mark Dickinson added the comment: > What should the format specifier mini-language for complex numbers look > like? > Should it look like the existing mini-language for floats, but have > the format specified twice, with some sort of delimiter? This sounds clumsy to me. I'd guess that in most

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Eric Smith added the comment: I agree this is a feature request. It comes down to: What should the format specifier mini-language for complex numbers look like? Should it look like the existing mini-language for floats, but have the format specified twice, with some sort of delimiter? Or just

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Daniel Diniz added the comment: Confirmed in py3k at rev71995. -- nosy: +ajaksu2, marketdickinson stage: -> test needed versions: +Python 3.1 ___ Python tracker ___

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Changes by Eric Smith <[EMAIL PROTECTED]>: -- nosy: +eric.smith __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe:

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Guido van Rossum added the comment: > I thought Python 3 was meant to be an _improvement_:-) That's why I didn't close the issue but reclassified it. Or did you expect me to implement it overnight? :-) __ Tracker <[EMAIL PROTECTED]>

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Mark Summerfield added the comment: On 2007-12-11, Guido van Rossum wrote: > Guido van Rossum added the comment: > > This really is a feature request -- in Python 2.x there is no formatting > code for complex numbers at all, and "%.5s" % complex(...) does the same > thing. > > I agree it would be

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Mark Summerfield added the comment: On 2007-12-11, Guido van Rossum wrote: > Guido van Rossum added the comment: > > This really is a feature request -- in Python 2.x there is no formatting > code for complex numbers at all, and "%.5s" % complex(...) does the same > thing. I thought Python 3 was

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Guido van Rossum added the comment: Maybe this would be a good GHOP task? __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscrib

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

Guido van Rossum added the comment: This really is a feature request -- in Python 2.x there is no formatting code for complex numbers at all, and "%.5s" % complex(...) does the same thing. I agree it would be neat to have control over complex numbers using the same formatting language used for f

[issue1588] str.format() wrongly formats complex() numbers (Py30a2)

New submission from Mark Summerfield: >>> x = complex(1, 2/3) >>> "{0} {0:.5}".format(x) '(1+0.6667j) (1+0.' The complex number is being formatted as if it were a string and simply truncated to 5 characters. I would expect each part of the complex number to be formatted according to the