Message 122487 - Python tracker

➜

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	belopolsky
Recipients	amaury.forgeotdarc, belopolsky, eric.smith, ezio.melotti, lemburg, pitrou, terry.reedy
Date	2010-11-27.00:08:30
SpamBayes Score	9.566145e-10
Marked as misclassified	No
Message-id	<AANLkTimjNAVQ_DDWbmGu023nqCUSEfyoO37upSduas12@mail.gmail.com>
In-reply-to	<1290814645.9.0.0262811772107.issue10521@psf.upfronthosting.co.za>

Content
On Fri, Nov 26, 2010 at 6:37 PM, Terry J. Reedy <report@bugs.python.org> wrote: > > Terry J. Reedy <tjreedy@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.

On Fri, Nov 26, 2010 at 6:37 PM, Terry J. Reedy <report@bugs.python.org> wrote:
>
> Terry J. Reedy <tjreedy@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.

History
Date	User	Action	Args
2010-11-27 00:08:31	belopolsky	set	recipients: + belopolsky, lemburg, terry.reedy, amaury.forgeotdarc, pitrou, eric.smith, ezio.melotti
2010-11-27 00:08:30	belopolsky	link	issue10521 messages
2010-11-27 00:08:30	belopolsky	create