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 terry.reedy
Recipients amaury.forgeotdarc, belopolsky, eric.smith, ezio.melotti, lemburg, pitrou, terry.reedy
Date 2010-11-26.23:37:24
SpamBayes Score 1.9428903e-13
Marked as misclassified No
Message-id <1290814645.9.0.0262811772107.issue10521@psf.upfronthosting.co.za>
In-reply-to
Content
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.

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. That model is not universally applicable, so I do not consider it a bug that functions based on that model are also not universally applicable. Perhaps docs should be clearer about the limitations of many of the string methods in the new context.

A full general solution to the general problem of centering requires a shift to physical units (points or mm) and detailed font information, including kerning. This is beyond the scope of a string method.

So I consider this a feature request for a partial generalization of unclear utility and unclear definition.
History
Date User Action Args
2010-11-26 23:37:25terry.reedysetrecipients: + terry.reedy, lemburg, amaury.forgeotdarc, belopolsky, pitrou, eric.smith, ezio.melotti
2010-11-26 23:37:25terry.reedysetmessageid: <1290814645.9.0.0262811772107.issue10521@psf.upfronthosting.co.za>
2010-11-26 23:37:24terry.reedylinkissue10521 messages
2010-11-26 23:37:24terry.reedycreate