[issue494873] add tests for complex numbers

Change by admin : -- github: None -> 35788 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue15996] pow() for complex numbers is rough around the edges

Mark Dickinson added the comment: See also discussion in #44970, which is closed as a duplicate of this issue. -- ___ Python tracker ___

[issue44344] Documentation for pow() should include the possibility of complex numbers as a return type

Łukasz Langa added the comment: Thanks, Mark! ✨  ✨ -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.10, Python 3.11 ___ Python tracker

[issue44344] Documentation for pow() should include the possibility of complex numbers as a return type

Łukasz Langa added the comment: New changeset c53428fe8980aab6eda3e573bafed657e6798e6e by Miss Islington (bot) in branch '3.9': bpo-44344: Document that pow can return a complex number for non-complex inputs. (GH-27853) (GH-29134)

[issue44344] Documentation for pow() should include the possibility of complex numbers as a return type

Łukasz Langa added the comment: New changeset 9b3cda56870d087cf50f605e91f3d26964868640 by Miss Islington (bot) in branch '3.10': bpo-44344: Document that pow can return a complex number for non-complex inputs. (GH-27853) (GH-29135)

[issue44344] Documentation for pow() should include the possibility of complex numbers as a return type

Change by miss-islington : -- pull_requests: +27411 pull_request: https://github.com/python/cpython/pull/29135 ___ Python tracker ___

[issue44344] Documentation for pow() should include the possibility of complex numbers as a return type

Change by miss-islington : -- nosy: +miss-islington nosy_count: 7.0 -> 8.0 pull_requests: +27410 pull_request: https://github.com/python/cpython/pull/29134 ___ Python tracker

[issue44344] Documentation for pow() should include the possibility of complex numbers as a return type

Łukasz Langa added the comment: New changeset 887a55705bb6c05a507c2886c9978a9e0cff0dd7 by Mark Dickinson in branch 'main': bpo-44344: Document that pow can return a complex number for non-complex inputs. (GH-27853)

[issue15996] pow() for complex numbers is rough around the edges

Terry J. Reedy added the comment: In Windows, I now get the Mark's macOS result instead of the Z.D.Error. >>> (1.0+0j)**(float('inf') + 0j) (nan+nanj) Has there been a revision of complex ** on another issue such that this one is obsolete? --

[issue44344] Documentation for pow() should include the possibility of complex numbers as a return type

Raymond Hettinger added the comment: The pow() docs could use substantial updating. All of the logic for pow() is implemented in base.__pow__(exp, [mod]). Technically, it isn't restricted to numeric types, that is just a norm. The relationship between "pow(a,b)" and "a**b" is that both

[issue44344] Documentation for pow() should include the possibility of complex numbers as a return type

Mark Dickinson added the comment: @Erik: Do you have a moment to look at the PR (GH-27853) and see if the proposed changes work for you? -- ___ Python tracker ___

[issue44344] Documentation for pow() should include the possibility of complex numbers as a return type

Change by Mark Dickinson : -- assignee: docs@python -> mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue44344] Documentation for pow() should include the possibility of complex numbers as a return type

Change by Mark Dickinson : -- keywords: +patch pull_requests: +26312 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27853 ___ Python tracker ___

[issue44344] Documentation for pow() should include the possibility of complex numbers as a return type

Mark Dickinson added the comment: > Perhaps we should just borrow from the documentation for the power operator, > which says [...] That sounds good to me. -- ___ Python tracker

[issue44344] Documentation for pow() should include the possibility of complex numbers as a return type

Erik Y. Adams added the comment: I still think the most important aspect of this is that pow() will return complex numbers, contrary to what is implied by the statement I quoted at the beginning of this thread. Perhaps we should just borrow from the documentation for the power operator

[issue44344] Documentation for pow() should include the possibility of complex numbers as a return type

Change by Steven D'Aprano : -- nosy: +steven.daprano ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44344] Documentation for pow() should include the possibility of complex numbers as a return type

Mark Dickinson added the comment: [Dennis] > I think the relevant property is that the exponent is not an integer Yep: the delegation to complex pow kicks in after handling infinities and nans, and only for strictly negative base (-0.0 doesn't count as negative for this purpose) and

[issue44344] Documentation for pow() should include the possibility of complex numbers as a return type

Dennis Sweeney added the comment: For some prior art, https://www.wolframalpha.com/input/?i=%28-8%29+%5E+%281%2F3%29 says it defaults to using "the principal root" over "the real-valued root" Also, I think the relevant property is that the exponent is not an integer; being between 0 and 1

[issue44344] Documentation for pow() should include the possibility of complex numbers as a return type

3)` will return `(1.0002+1.7320508075688772j)`, and not `-2.0.`" -- assignee: docs@python components: Documentation messages: 395305 nosy: docs@python, eyadams priority: normal severity: normal status: open title: Documentation for pow() should include the possibility

[issue43025] Use normal 'i' character to denote imaginary part of complex numbers

Eric V. Smith added the comment: Thanks, Mark. I'll just close it now. I've made a reminder about the PEP, but not sure when/if I'll get to it. -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker

[issue43025] Use normal 'i' character to denote imaginary part of complex numbers

Mark Dickinson added the comment: @Eric: Are you okay with closing this issue, or do you think we should leave it open as a reminder to write that PEP? -- ___ Python tracker

[issue43025] Use normal 'i' character to denote imaginary part of complex numbers

Raymond Hettinger added the comment: Unfortunately, this ship sailed a long time ago. Changing it now would create more problems that it solves. > I doubt that that will be enough to silence the repeated requests: > people are still going to complain that the value that was entered > as

[issue43025] Use normal 'i' character to denote imaginary part of complex numbers

Mark Dickinson added the comment: [Serhiy] > Just making the parser [...] recognizing "i" as well as "j" as complex number > suffix. Okay, thanks. I doubt that that will be enough to silence the repeated requests: people are still going to complain that the value that was entered as `1i`

[issue43025] Use normal 'i' character to denote imaginary part of complex numbers

Serhiy Storchaka added the comment: Just making the parser (and the complex constructor) recognizing "i" as well as "j" as complex number suffix. Others already proposed more complex changes like adding options for formatting complex numbers, but I did not though a

[issue43025] Use normal 'i' character to denote imaginary part of complex numbers

Change by Serhiy Storchaka : -- versions: +Python 3.10 -Python 3.9 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue43025] Use normal 'i' character to denote imaginary part of complex numbers

Mark Dickinson added the comment: Serhiy: what *specific* proposal were you considering? If your proposal includes changing the complex str/repr to use "i" instead of "j", how do you propose to address the backwards compatibility problem? -- ___

[issue43025] Use normal 'i' character to denote imaginary part of complex numbers

Serhiy Storchaka added the comment: Only yesterday I thought about proposing this idea. I used to think using "i" or "j" was a type of local feature, like using a comma or a period as a decimal separator, or different writing for less-or-equal, but it looks like even in the English-speaking

[issue43025] Use normal 'i' character to denote imaginary part of complex numbers

Mark Dickinson added the comment: > cmath.nanj That should be cmath.nani, of course. Sorry. -- ___ Python tracker ___ ___

[issue43025] Use normal 'i' character to denote imaginary part of complex numbers

Mark Dickinson added the comment: See also #10562. Conceivably, we could add support for `i` on parsing (along with adding `cmath.infi` and `cmath.nanj`). We can probably also find a way to extend the format specification to allow use of `i` in place of `j` on output. The harder problem

[issue43025] Use normal 'i' character to denote imaginary part of complex numbers

Eric V. Smith added the comment: Good point on surveying other languages for a PEP. You're further along in your thinking than I am! -- ___ Python tracker ___

[issue43025] Use normal 'i' character to denote imaginary part of complex numbers

Steven D'Aprano added the comment: I think it always helps to look at what other languages do. It doesn't mean that we must follow them, but it may help us decide that the choice made in Python 1 was a mistake and it is worth going through the pain of deprecation, or that it is still

[issue43025] Use normal 'i' character to denote imaginary part of complex numbers

and switch to 'i'. I don't think either option makes sense. -- title: Use normal 'i -> Use normal 'i' character to denote imaginary part of complex numbers ___ Python tracker <https://bugs.python.org/issu

[issue43025] Use normal 'i' character to denote imaginary part of complex numbers

Eric V. Smith added the comment: As I said in msg385648, I don't think it's feasible. Maybe I'll write a PEP just to get it rejected so we can point to it when this discussion comes up, which it does a few times a year. -- ___ Python tracker

[issue43025] Use normal 'i' character to denote imaginary part of complex numbers

Emmanuel Arias added the comment: > Now, it's feasible change i for j on cpython? Asking from my ignorance on > this case. j for i, sorry -- ___ Python tracker ___

[issue43025] Use normal 'i' character to denote imaginary part of complex numbers

Emmanuel Arias added the comment: Personally, it's more natural use 'j' for complex number, but it's true that in many math book (or that I used) letter 'i' is used. Now, it's feasible change i for j on cpython? Asking from my ignorance on this case. -- nosy: +eamanu

[issue43025] Use normal 'i' character to denote imaginary part of complex numbers

Eric V. Smith added the comment: Even if we wanted to switch to "i" we'd have to continue to also support "j": there's a ton of existing code that uses it. Since "j" is used by some fields (including my own) for the imaginary part of complex numbers, and since

[issue43025] Use normal 'i' character to denote imaginary part of complex numbers

Christian Heimes added the comment: Your statement is not correct. A lot of people use "j" in fields of electrical engineering and signal processing to express the imaginary part. The letter "i" is commonly used for electric current in these fields. -- nosy: +christian.heimes

[issue43025] Use normal 'i' character to denote imaginary part of complex numbers

Bhuvanesh Bhatt added the comment: Nobody these days uses j to represent the imaginary part of complex numbers. Regardless of what Guido wrote earlier, this issue should be fixed. -- title: Use normal 'i -> Use normal 'i' character to denote imaginary part of complex numbers t

Complex numbers

This module implements cplx class (complex numbers) regardless to the built-in class. The main goal of this module is to propose some improvement to complex numbers in python and deal with them from a mathematical approach. Also cplx class doesn't support the built-in class intentionally

Complex numbers

This module implements cplx class (complex numbers) regardless to the built-in class. The main goal of this module is to propose some improvement to complex numbers in python and deal with them with a mathematical approach. I chose not to support the built-in class in this module, as the idea

[issue27363] Complex numbers with negative zero parts do not roundtrip properly

Vedran Čačić added the comment: Since I'm so happy with Fraction being fixed, I'll agree here. :-) -- ___ Python tracker ___

[issue27363] Complex numbers with negative zero parts do not roundtrip properly

Mark Dickinson added the comment: > Unfortunately, as http://bugs.python.org/issue23229#msg233965 shows, Guido is > against changing complex.__repr__. Good catch! I think that means we should close this issue. The current behaviour isn't actually wrong; it's just a compromise between lots of

[issue27363] Complex numbers with negative zero parts do not roundtrip properly

Vedran Čačić added the comment: Unfortunately, as http://bugs.python.org/issue23229#msg233965 shows, Guido is against changing complex.__repr__. Is there any chance someone could show this discussion to him, to show how it would help and try to change his mind? --

[issue27363] Complex numbers with negative zero parts do not roundtrip properly

Changes by ppperry <maprea...@olum.org>: -- title: Complex numbers with negative zero imaginary parts do not roundtrip properly -> Complex numbers with negative zero parts do not roundtrip properly ___ Python tracker <rep...@bugs.pytho

[issue27363] Complex numbers with negative zero imaginary parts do not roundtrip properly

Changes by ppperry <maprea...@olum.org>: -- title: Complex with negative zero imaginary part -> Complex numbers with negative zero imaginary parts do not roundtrip properly ___ Python tracker <rep...@bugs.python.org> <http

[issue19381] Seg Fault with complex numbers

components: Macintosh messages: 201190 nosy: Manish.Raghavan, ronaldoussoren priority: normal severity: normal status: open title: Seg Fault with complex numbers type: crash versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org

[issue19381] Seg Fault with complex numbers

Changes by Benjamin Peterson benja...@python.org: -- resolution: - duplicate status: open - closed superseder: - interactive interpreter crashes and test_readline fails on OS X 10.9 Mavericks due to libedit update ___ Python tracker

[issue19381] Seg Fault with complex numbers

Changes by Ezio Melotti ezio.melo...@gmail.com: -- stage: - committed/rejected ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19381 ___ ___

[issue15996] pow() for complex numbers is rough around the edges

Mark Dickinson added the comment: See also http://stackoverflow.com/q/18243270/270986 , which points out the following inconsistencies: 1e300 ** 2 OverflowError: (34, 'Result too large') 1e300j ** 2 OverflowError: complex exponentiation (1e300 + 1j) ** 2 OverflowError: complex

[issue15996] pow() for complex numbers is rough around the edges

Raymond Hettinger added the comment: OS math libraries are bad enough at *float* math, let alone complex; I'd rather not depend on them unless we have to. This makes good sense. We should control how the special cases resolve and not be subject the whims of various C libraries.

[issue15996] pow() for complex numbers is rough around the edges

Mark Dickinson added the comment: Reclassifying this as an enhancement; I don't think it's appropriate to rewrite complex_pow for the bugfix releases. -- type: behavior - enhancement versions: -Python 3.3 ___ Python tracker rep...@bugs.python.org

[issue15996] pow() for complex numbers is rough around the edges

Changes by Jesús Cea Avión j...@jcea.es: -- nosy: +jcea stage: test needed - type: enhancement - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15996 ___

[issue15996] pow() for complex numbers is rough around the edges

Changes by Jesús Cea Avión j...@jcea.es: -- stage: - test needed type: behavior - enhancement ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15996 ___

[issue15996] pow() for complex numbers is rough around the edges

Mark Dickinson added the comment: (1.0+0j)**(float('inf') + 0j) Oddly enough, this is nan+nanj on OS X. I haven't investigated what the difference is due to---probably something to do with the errno results. -- ___ Python tracker

[issue15996] pow() for complex numbers is rough around the edges

Changes by Serhiy Storchaka storch...@gmail.com: -- nosy: +storchaka ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15996 ___ ___ Python-bugs-list

[issue15996] pow() for complex numbers is rough around the edges

Mark Dickinson added the comment: Well, C99 covers pow for *real* numbers just fine; it's complex numbers where no-one wants to pin down what the behaviour should be. So I don't think we need the man page reference. If we're writing tests for complex pow, we might also want to consider

[issue15996] pow() for complex numbers is rough around the edges

Serhiy Storchaka added the comment: Well, C99 covers pow for *real* numbers just fine; it's complex numbers where no-one wants to pin down what the behaviour should be. C99 contains cpow. Perhaps we should use conditional compilation

[issue15996] pow() for complex numbers is rough around the edges

Mark Dickinson added the comment: C99 contains cpow. Perhaps we should use conditional compilation? I dread to think what horrors lurk in OS math library implementations of cpow; I suspect we'd soon find out, if we had used cpow and have any tests at all for special cases. OS math

[issue15996] pow() for complex numbers is rough around the edges

Terry J. Reedy added the comment: Given that 1.0**float('inf'), 1.0**float('-inf') (1.0, 1.0) works, (1.0+0j)**(float('inf') + 0j) Traceback ... ZeroDivisionError: 0.0 to a negative or complex power (and same for ('-inf') seems like a clear bug in raising an exception, let alone a clearly

[issue15996] pow() for complex numbers is rough around the edges

: Interpreter Core files: rcomplex_testcases2.txt messages: 170856 nosy: mark.dickinson, mattip priority: normal severity: normal status: open title: pow() for complex numbers is rough around the edges type: behavior Added file: http://bugs.python.org/file27238/rcomplex_testcases2.txt

[issue15996] pow() for complex numbers is rough around the edges

Changes by Alex Gaynor alex.gay...@gmail.com: -- nosy: +alex ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15996 ___ ___ Python-bugs-list mailing

[issue4907] ast.literal_eval does not properly handled complex numbers

Raymond Hettinger rhettin...@users.sourceforge.net added the comment: Fixed handling on unary minus in r85314. In so doing, it also liberalized what literal_eval() accepts (3j+4 for example). This simplified the implementation and removed an unnecessary restriction which wasn't needed for

trouble with complex numbers

this message in context: http://www.nabble.com/trouble-with-complex-numbers-tp24821423p24821423.html Sent from the Python - python-list mailing list archive at Nabble.com. -- http://mail.python.org/mailman/listinfo/python-list

Re: trouble with complex numbers

On Tue, Aug 4, 2009 at 11:28 PM, Dr. Phillip M. Feldmanpfeld...@verizon.net wrote: When I try to compute the phase of a complex number, I get an error message: In [3]: from cmath import * In [4]: x=1+1J In [5]: phase(x) snip NameError: name 'phase' is not defined snip AttributeError:

Re: trouble with complex numbers

On Aug 5, 4:28 pm, Dr. Phillip M. Feldman pfeld...@verizon.net wrote: When I try to compute the phase of a complex number, I get an error message: [...] Any advice will be appreciated. 1. What version of Python are you using, and on what platform? 2. What you snipped is necessary to help

Re: trouble with complex numbers

Dr. Phillip M. Feldman wrote: When I try to compute the phase of a complex number, I get an error message: In [3]: from cmath import * In [4]: x=1+1J In [5]: phase(x) snip NameError: name 'phase' is not defined snip AttributeError: 'complex' object has no attribute 'phase' Any advice will be

Re: trouble with complex numbers

Christian Heimes li...@cheimes.de (CH) wrote: CH You can write your own phase() function. This function is mostly correct CH unless either the real and/or the imag part is NaN or INF. CH from math import atan2 CH def phase(z): CH z += 1j # convert int, long, float to complex That should

Re: trouble with complex numbers

Piet van Oostrum p...@cs.uu.nl wrote: That should be z += 0j Pardon my ignorance, but could anyone explain the rationale behind using 'j' to indicate the imaginary number (as opposed to the more intuitive 'i')? (Not that I've had much call to use complex numbers but I'm curious) -- http

Re: trouble with complex numbers

alex23 wrote: Piet van Oostrum p...@cs.uu.nl wrote: That should be z += 0j Pardon my ignorance, but could anyone explain the rationale behind using 'j' to indicate the imaginary number (as opposed to the more intuitive 'i')? (Not that I've had much call to use complex numbers but I'm curious

Re: trouble with complex numbers

On Aug 6, 1:18 am, Scott David Daniels scott.dani...@acm.org wrote: I think it explained in the complex math area, but basically EE types use j, math types use i for exactly the same thing.  Since i is so frequently and index in CS, and there is another strong convention, why not let the EE

Re: trouble with complex numbers

On Wed, 05 Aug 2009 08:18:55 -0700, Scott David Daniels scott.dani...@acm.org wrote: I think it explained in the complex math area, but basically EE types use j, math types use i for exactly the same thing. Since i is so frequently and index in CS, and there is another strong convention, why not

Re: trouble with complex numbers

part is NaN or INF. from math import atan2 def phase(z): z += 1j # convert int, long, float to complex return atan2(z.imag, z.real) -- http://mail.python.org/mailman/listinfo/python-list -- View this message in context: http://www.nabble.com/trouble-with-complex-numbers

Re: trouble with complex numbers

On 2009-08-05 15:16, Dr. Phillip M. Feldman wrote: I am using Python 2.5, and most of the cmath functions are not yet available in this version. Thanks! Phillip P.S. In your code, that should be x+= 0J P.P.S. I wish that the documentation indicated anything that is new. It does.

Re: trouble with complex numbers

On Wed, 05 Aug 2009 15:27:51 -0500, Robert Kern wrote: On 2009-08-05 15:16, Dr. Phillip M. Feldman wrote: I am using Python 2.5, and most of the cmath functions are not yet available in this version. Thanks! Phillip P.S. In your code, that should be x+= 0J P.P.S. I wish that the

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

Mark Dickinson dicki...@gmail.com added the comment: Yes, this is a separate issue. Thanks. See issue 5920. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1588 ___

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

Mark Dickinson dicki...@gmail.com 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

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

Eric Smith e...@trueblade.com 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 rep...@bugs.python.org

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

Mark Dickinson dicki...@gmail.com 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 e...@trueblade.com 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

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

Mark Dickinson dicki...@gmail.com added the comment: With these patches, all tests pass for me both for py3k and trunk. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1588 ___

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

Mark Dickinson dicki...@gmail.com 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 rep...@bugs.python.org http://bugs.python.org/issue1588

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

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

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

Mark Dickinson dicki...@gmail.com 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

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

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

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

Mark Dickinson dicki...@gmail.com 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

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

Eric Smith e...@trueblade.com 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,

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

Mark Dickinson dicki...@gmail.com 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.

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

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

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

by 100 before using fixed-point formatting). The real issue whether to have two trailing '%'s or one. Just being difficult: I completely agree that '%' should be disallowed for complex numbers. -- ___ Python tracker rep...@bugs.python.org http

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

Eric Smith e...@trueblade.com 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 rep...@bugs.python.org

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

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

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

Eric Smith e...@trueblade.com 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 rep...@bugs.python.org

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

Mark Dickinson dicki...@gmail.com 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')

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

Eric Smith e...@trueblade.com 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)

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

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

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

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

Changes by Eric Smith e...@trueblade.com: Added file: http://bugs.python.org/file13808/issue-1588-py3k.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1588 ___

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

Changes by Eric Smith e...@trueblade.com: Removed file: http://bugs.python.org/file13801/issue-1588-0.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1588 ___

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

Changes by Eric Smith e...@trueblade.com: Removed file: http://bugs.python.org/file13802/issue-1588-1-py3k.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1588 ___

  1   2   3   >