Complex representation

[hwundram]

BPO	1491866
Nosy	@terryjreedy
Files	python-complex.diff: Complex constructor patch to accept bracketed values.

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2007-03-09.20:33:47.000>
created_at = <Date 2006-05-19.21:27:31.000>
labels = ['interpreter-core']
title = 'Complex representation'
updated_at = <Date 2007-03-09.20:33:47.000>
user = 'https://bugs.python.org/hwundram'

bugs.python.org fields:

activity = <Date 2007-03-09.20:33:47.000>
actor = 'collinwinter'
assignee = 'collinwinter'
closed = True
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2006-05-19.21:27:31.000>
creator = 'hwundram'
dependencies = []
files = ['7268']
hgrepos = []
issue_num = 1491866
keywords = ['patch']
message_count = 7.0
messages = ['50297', '50298', '50299', '50300', '50301', '50302', '50303']
nosy_count = 4.0
nosy_names = ['collinwinter', 'terry.reedy', 'sonderblade', 'hwundram']
pr_nums = []
priority = 'normal'
resolution = 'accepted'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1491866'
versions = ['Python 2.6']

[hwundram]

As per request on c.l.p:

http://groups.google.de/group/comp.lang.python/browse_thread/thread/26c93fefefd3a100/bf1924ce28fac1ac?hl=de#bf1924ce28fac1ac

I've implemented a small patch to change the output of
repr(x) for complex variables, so that complex(repr(x))
works for any complex x. This changes the output of
repr(x) to

'<r>+<i>j'

without brackets, but leaves the string output
untouched. This change of behaviour would be in line
with int(repr(x)) and float(repr(x)) being defined for
any int or float x, repectively.

I don't know whether this patch is sensible, and
whether it breaks any current code, because (for example)

eval("5*%r" % (1+2j,))

won't work properly anymore, or whether it'd be more
sensible to change the complex constructor to also
accept a bracketed expression. I'll attach a patch to
do the latter later.

[hwundram]

Logged In: YES
user_id=791932

The second patch (python-complex-constructor.diff) changes
the constructor to accept bracketed complex numbers which
are enclosed in a single bracket. I'd rather say this is the
better appropach to have complex(repr(x)) work, but I leave
both patches attached to this bug.

The latter patch also creates test cases testing for
formatting errors with bracketed expressions.

[terryjreedy]

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.

[hwundram]

Logged In: YES
user_id=791932

The attached patch is a revised version of the patch to the
complex 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 a
bug was by accident: I should've rather called it tracker
item, which is pretty synonymous for me.

[sonderblade]

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.

[collinwinter]

Works for me. I'll commit this for 2.6 (no backport) if there are no objections.

[collinwinter]

Applied as r54247. Thanks for your patch!