[issue10521] str methods don't accept non-BMP fillchar on a narrow Unicode build

Alexander Belopolsky report at bugs.python.org
Sat Nov 27 01:08:31 CET 2010

Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Nov 26, 2010 at 6:37 PM, Terry J. Reedy <report at bugs.python.org> wrote:
> Terry J. Reedy <tjreedy at udel.edu> added the comment:
> As a practical matter, I think that for at least the next decade, people are at least as likely to
> want to fill with a composed, multi-BMP-codepoint 'char' (grapheme) as with a non-BMP char.
> So to me, failure with the latter is no worse than failure with the former.

I disagree. '\N{AEGEAN WORD SEPARATOR DOT}'  ('𐄁') looks like a
reasonably shaped fill character, while say 'Z\N{COMBINING ACUTE
ACCENT}\N{COMBINING GRAVE ACCENT}' ('Ź̀') does not.  Yet this is not
the point of this bug report.  The point is that Python user should
not care (much) about how many bytes per character Python uses under
the hood or what is the numeric value of the character that she can
enter in her program.

> The underlying problem is that centering k chars within n spaces with fill i is based
> on one-char per code encodings *and* fixed pitch fonts with one-char per space.

No. ' Section Title '.center(40, '*') will look good regardless of
font width and even more so when combined with <center> tag or its
equivalent in a given application.


Python tracker <report at bugs.python.org>

More information about the Python-bugs-list mailing list