Eric V. Smith added the comment:
I agree with David: It's unfortunate, but too late to change.
FWIW, since the goal is to replace just str.center, I'd write this as:
def my_center(s, width):
return format(s, '^' + str(width))
As soon as you're mixing in other formatting, then str.center
R. David Murray added the comment:
I would write it:
{:^{width}}.format(title, width=width)
By the way, in case it isn't clear, we acknowledge that in a perfect world
center would work right, but our judgment is that the pain of fixing it
outweighs the benefit. Our collective consensus
Vedran Čačić added the comment:
Only one detail to resolve: you say format is quite capable of handing a
variable width field.
It does, but not in a really nice way. Honestly, would you really rather see
{:^{}}.format(title, width)
than
title.center(width)
? Nested formats are
Vedran Čačić added the comment:
Ok, let's say I see your point about breaking existing code (though, I
reiterate, it's _undocumented_ and even examples in the docs all cover only the
obvious case).
Is it _at least_ possible to give .center an (keyword-only if needed) argument
that specifies
R. David Murray added the comment:
Backward compatibility does not mean matches the docs, it means if we change
this, someone's existing code is likely to break. That does not prevent us
from making at-the-margin changes in a feature release, but it is still a bar
to be overcome in making
Raymond Hettinger added the comment:
[Serhiy]
The behavior of Python 2.7 is the same as Python 3.x.
str.center() is very old method and changing it will change
formatted reports generated by third-party software in all world.
At least this will break many tests. And this will add yet one
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
assignee: - rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23624
___
___
Vedran Čačić added the comment:
We can make a poll, I think it is quite obvious. But that's not really the
point.
I would accept the solution enabling _both_ methods of rounding with _both_
methods of formatting (it isn't even very hard to do: .center can take
additional argument, mandatory
Serhiy Storchaka added the comment:
The behavior of Python 2.7 is the same as Python 3.x.
str.center() is very old method and changing it will change formatted reports
generated by third-party software in all world. At least this will break many
tests. And this will add yet one
Vedran Čačić added the comment:
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
Serhiy Storchaka added the comment:
The problem is that it is not *obvious* what method is more correct.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23624
___
Eric V. Smith added the comment:
I agree it would be nice to be consistent, and that str.__format__'s approach
is likely the desirable one.
But is it worth the breakage? Surely someone cares about the current behavior.
Does this cause any practical, real-world problem?
--
Raymond Hettinger added the comment:
FWIW, I prefer the approach which always puts the odd pad character on the
right. I believe this is what most typists would do. Ideally, the behavior
should be the same as in Python 2 (before ROOUND-HALF-EVEN) so that templates
don't change their
Changes by Eric V. Smith e...@trueblade.com:
--
nosy: +eric.smith
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23624
___
___
Python-bugs-list
Vedran Čačić added the comment:
If I see right, it seems that that (putting odd pad character on the right) is
exactly what format does (I don't have Py2 here to check how exactly it
behaves). So, the current proposition to change the .center to match format
stays.
(I think I can see how the
New submission from Vedran Čačić:
Look at this:
format(ab, ^3), ab.center(3)
('ab ', ' ab')
format(abc, ^4), abc.center(4)
('abc ', 'abc ')
I'm sure you agree this is inconsistent. As far as I can see, format relies on
// (flooring) behaviour when dividing remaining space by
16 matches
Mail list logo
