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) *  |
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) *  |
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) *  |
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) *  |
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) *  |
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) *  |
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) *  |
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) *  |
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) *  |
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) *  |
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. |
|
|