| Messages (7) |
|---|
| msg50297 -(view) | Author: Heiko Wundram (hwundram) | Date: 2006-05-19 21:27 |
|---|
As per request on c.l.p:http://groups.google.de/group/comp.lang.python/browse_thread/thread/26c93fefefd3a100/bf1924ce28fac1ac?hl=de#bf1924ce28fac1acI've implemented a small patch to change the output ofrepr(x) for complex variables, so that complex(repr(x))works for any complex x. This changes the output ofrepr(x) to'<r>+<i>j'without brackets, but leaves the string outputuntouched. This change of behaviour would be in linewith int(repr(x)) and float(repr(x)) being defined forany int or float x, repectively.I don't know whether this patch is sensible, andwhether it breaks any current code, because (for example)eval("5*%r" % (1+2j,))won't work properly anymore, or whether it'd be moresensible to change the complex constructor to alsoaccept a bracketed expression. I'll attach a patch todo the latter later. |
| msg50298 -(view) | Author: Heiko Wundram (hwundram) | Date: 2006-05-19 22:28 |
|---|
Logged In: YES user_id=791932The second patch (python-complex-constructor.diff) changesthe constructor to accept bracketed complex numbers whichare enclosed in a single bracket. I'd rather say this is thebetter appropach to have complex(repr(x)) work, but I leaveboth patches attached to this bug.The latter patch also creates test cases testing forformatting errors with bracketed expressions. |
| msg50299 -(view) | Author: Terry J. Reedy (terry.reedy)* | Date: 2006-05-20 05:24 |
|---|
Logged In: YES user_id=593130(The current behavior is not a bug, nor is this patch submission a bug report, so let us omit that word.)I think your example suggests why complexes are printed in parens, so I think enhancing complex() to accept such is the better approach if any change is to be made. |
| msg50300 -(view) | Author: Heiko Wundram (hwundram) | Date: 2006-05-20 11:20 |
|---|
Logged In: YES user_id=791932The attached patch is a revised version of the patch to thecomplex constructor to accept bracketed string expressions,which also adds documentation changes (whatsnew25).Anyway, I personally also find this to be the "better" way,so I've removed the repr-changing patch. And, calling it abug was by accident: I should've rather called it trackeritem, which is pretty synonymous for me. |
| msg50301 -(view) | Author: Björn Lindqvist (sonderblade) | Date: 2007-03-08 00:04 |
|---|
I have applied this patch in 2.6 and it seem to work as intended. The test_complex.py unit tests all pass. I guess the change could be useful if you are are serializing and desearializing lists of complex numbers. I think it should be applied. |
| msg50302 -(view) | Author: Collin Winter (collinwinter)* | Date: 2007-03-08 19:09 |
|---|
Works for me. I'll commit this for 2.6 (no backport) if there are no objections. |
| msg50303 -(view) | Author: Collin Winter (collinwinter)* | Date: 2007-03-09 20:33 |
|---|
Applied asr54247. Thanks for your patch! |