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.

Author veky
Recipients eric.smith, rhettinger, serhiy.storchaka, veky
Date 2015-03-10.09:59:38
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1425981578.5.0.353639374789.issue23624@psf.upfronthosting.co.za>
In-reply-to
Content
By that line of reasoning, we would probably never change anything. :-( I searched the documentation, and the exact behaviour isn't documented anywhere. In fact all examples are of the kind where there is an even number of fill chars. I thought it was ok to "break" undocumented things.

As for a practical problem, here is how I encountered it. I had a format that centered something inside a constant-width column. format("^79", title) it was, I think. Then, as it usually happens, things were generalized and the width was customizable. Of course, I could have used "{:^{}}".format(title, width), but title.center(width) really seemed like a better option.

Imagine my horror when a test failed. At first I thought, ok, format puts extra space on one side, .center at the other, no big deal. But then I changed it, and it failed again. Many time and lost nerves later (not something I usually associate with Python), I realized that those two use different _methods_ of calculating the distribution of spaces.

At that moment, I really thought it must be a bug. But I went to the docs, and they never said anything about where an extra fill char is put. So yes, it is _theoretically_ possible that this is exactly the intended behaviour. But I really think it's not the case.
History
Date User Action Args
2015-03-10 09:59:38vekysetrecipients: + veky, rhettinger, eric.smith, serhiy.storchaka
2015-03-10 09:59:38vekysetmessageid: <1425981578.5.0.353639374789.issue23624@psf.upfronthosting.co.za>
2015-03-10 09:59:38vekylinkissue23624 messages
2015-03-10 09:59:38vekycreate