Alexander Belopolsky <belopol...@users.sourceforge.net> added the comment:
On Fri, Nov 26, 2010 at 6:37 PM, Terry J. Reedy <rep...@bugs.python.org> wrote:
>
> Terry J. Reedy <tjre...@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 <rep...@bugs.python.org>
<http://bugs.python.org/issue10521>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
