This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: >>> 1 + 2j --> (1 + 2j) and not (1+2j)
Type: enhancement Stage:
Components: Interpreter Core Versions: Python 3.3
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: Retro, eric.araujo, eric.smith, eric.snow, gvanrossum, mark.dickinson
Priority: normal Keywords:

Created on 2010-12-04 09:21 by Retro, last changed 2022-04-11 14:57 by admin. This issue is now closed.

Messages (14)
msg123324 - (view) Author: Boštjan Mejak (Retro) Date: 2010-12-04 09:21
Python interpreter should put spaces around operators in return values of complex numbers. If you give it
>>> 1 + 2j
it should return
(1 + 2j)
and not the current
(1+2j)

My argument is that complex numbers are written like this, with spaces surrounding operators. Wikipedia has multiple instances of the complex number writren, and it's x + yi (in our world it's x + yj but you get the point and you can see that there are spaces around the operator). Please fix the tokenizer to do the right thing.
msg123330 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-12-04 10:38
I suggest closing this as 'won't fix' (or even the apostrophetically-challenged 'wont fix').  I'll leave it open for a while to allow others to comment.

I have some sympathy for the idea: I also think that the str/repr of a complex number would look better with spaces (and without parentheses (and with 'i' in place of 'j'))).  I've always appreciated the fact that lists are printed in the form '[1, 2, 3]' rather than the less readable '[1,2,3]'.

But there's a big difference between 'it might have been better if ...' and 'it's worth changing this'.  Tinkering with minor details like this from release to release just isn't worth the potential difficulties (however minor) caused to users as they have to adapt their code.  The current behaviour is perfectly serviceable.

P.S.  What's the tokenizer got to do with this?
msg123341 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2010-12-04 12:30
I agree. It would be nice, but the impact on existing code is too large. I can easily imagine someone parsing the output of "print(somecomplexnumber)" and not considering spaces.

For the record, it would require changing complex.__repr__  (which is also complex.__str__) and complex.__format__.

Now that I look at the code, it seems that complex_format is only called from one place (complex_repr), with fixed parameters. It could be moved into complex_repr for what I think is a small improvement in readability.
msg123342 - (view) Author: Boštjan Mejak (Retro) Date: 2010-12-04 12:51
Please do the move to complex_repr if everything then works the same (i.e.
nothing breaks the build) if the readability is in fact improved. Also,
change the docs and fix the tests. You know the drill.

P.S.: (1+2j) is worth changing to become (1 + 2j) in the future (in Python
3.3 if not sooner?). Is it very hard to do this? It's worth changing this.
Reasons like 'Readability counts.' come into mind...
msg123343 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2010-12-04 12:55
There are no tests or docs to fix: it's an internal (static) helper function.

It's not a particularly straightforward change, because you're inserting a space into the middle of the floating point imaginary string. There would be extra bookkeeping and memory management going on.

But even if it were easy, I disagree that it's worth breaking existing usages of complex.__str__, .__repr__, and .__format__.
msg123363 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-12-04 15:34
-1 on the change.

Retro: would you mind stop sending HTML email to this tracker?  It creates unnamed attachments that are distracting.  Thanks in advance.
msg123365 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2010-12-04 15:58
Okay, closing as 'wont fix'.
msg123369 - (view) Author: Boštjan Mejak (Retro) Date: 2010-12-04 16:51
Do you ever fix anything?
msg123379 - (view) Author: Éric Araujo (eric.araujo) * (Python committer) Date: 2010-12-04 17:41
Not much: http://bugs.python.org/issue?%40search_text=&ignore=file%3Acontent&title=&%40columns=title&id=&%40columns=id&stage=&creation=&creator=&activity=&%40columns=activity&%40sort=activity&actor=&nosy=&type=&components=&versions=&dependencies=&assignee=&keywords=&priority=&%40group=priority&status=2&%40columns=status&resolution=3&nosy_count=&message_count=&%40pagesize=50&%40startwith=0&%40queryname=&%40old-queryname=&%40action=search
msg148012 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2011-11-20 21:47
I'm not sure why this is being reopened. Unless there's been a discussion I'm not aware of, the change is still not worth the disruption it would cause.

And in any event, it can only be addressed in new (as yet unreleased) versions of python. It would never be implemented in any release before 3.3.
msg148075 - (view) Author: Boštjan Mejak (Retro) Date: 2011-11-21 19:32
Make the output of a complex expression include spaces around the operator. So, for example, (1+2j) should be outputted as (1 + 2j). Make this happen in Python 3.3.
msg148077 - (view) Author: Eric V. Smith (eric.smith) * (Python committer) Date: 2011-11-21 19:44
I'm -1 on this change. I think all the core devs who have commented on it here are -1 or -0. If you really want to lobby for this change, I suggest starting a discussion on python-dev.

My position is that I think it would indeed look nicer, but the breakage doesn't justify the small improvement.
msg148079 - (view) Author: Eric Snow (eric.snow) * (Python committer) Date: 2011-11-21 19:53
@eric.smith: +1

@Retro: If you are intent on pushing this, please take it to python-ideas@python.org.  However, judging from the response in this ticket and #10562, you won't get much traction.
msg148084 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2011-11-21 20:17
@Retro, stop reopening bugs. This is very much a matter of personal taste and the existing way is fine.
History
Date User Action Args
2022-04-11 14:57:09adminsetgithub: 54830
2011-11-21 20:17:25gvanrossumsetstatus: open -> closed
resolution: remind -> rejected
messages: + msg148084
2011-11-21 19:53:00eric.snowsetnosy: + eric.snow
messages: + msg148079
2011-11-21 19:44:58eric.smithsetmessages: + msg148077
2011-11-21 19:32:10Retrosetstatus: closed -> open

nosy: + gvanrossum
messages: + msg148075

resolution: wont fix -> remind
2011-11-20 21:47:59eric.smithsetstatus: open -> closed
resolution: remind -> wont fix
messages: + msg148012

versions: - Python 2.6, Python 3.1, Python 2.7, Python 3.2, Python 3.4
2011-11-20 21:36:20Retrosetversions: + Python 3.3, Python 3.4
2011-11-20 21:35:54Retrosetversions: + Python 2.6, Python 3.1, Python 2.7, Python 3.2, - Python 3.3
2011-11-20 21:34:52Retrosetstatus: closed -> open
resolution: wont fix -> remind
versions: + Python 3.3, - Python 3.1, Python 2.7, Python 3.2
2010-12-04 17:41:07eric.araujosetmessages: + msg123379
2010-12-04 17:09:37eric.smithsetfiles: - unnamed
2010-12-04 16:51:32Retrosetfiles: + unnamed

messages: + msg123369
2010-12-04 15:58:27mark.dickinsonsetnosy: mark.dickinson, eric.smith, eric.araujo, Retro
type: enhancement
components: + Interpreter Core, - IO
2010-12-04 15:58:00mark.dickinsonsetstatus: open -> closed
resolution: wont fix
messages: + msg123365
2010-12-04 15:34:25eric.araujosetnosy: + eric.araujo
messages: + msg123363
2010-12-04 15:33:46eric.araujosetfiles: - unnamed
2010-12-04 12:55:19eric.smithsetmessages: + msg123343
2010-12-04 12:51:10Retrosetfiles: + unnamed

messages: + msg123342
2010-12-04 12:30:22eric.smithsetnosy: + eric.smith
messages: + msg123341
2010-12-04 10:38:28mark.dickinsonsetnosy: + mark.dickinson
messages: + msg123330
2010-12-04 09:21:48Retrocreate