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 vstinner
Recipients Arfrever, Nicholas.Cole, benjamin.peterson, eric.araujo, ezio.melotti, inigoserna, lemburg, loewis, poq, tchrist, vstinner, zeha
Date 2012-03-19.12:59:05
SpamBayes Score 1.110223e-16
Marked as misclassified No
Message-id <1332161946.76.0.987175844351.issue12568@psf.upfronthosting.co.za>
In-reply-to
Content
> Martin: I agree that there are going to be cases where it is not
> correct because the terminal does something strange, but what we
> need is something that gets as close as possible to what the
> terminal is likely to be doing

Can't we expose wcswidth() as locale.strwidth() with a recipe explaining how to use unicodedata to get a "correct" result? At least until everyone implements correctly Unicode and Unicode stops evolving? :-)

--

For unicodedata, a function to get the width of a string would be more convinient than unicodedata.east_asian_width():

>>> import unicodedata
>>> unicodedata.east_asian_width('abc')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: need a single Unicode character as parameter
>>> 'abc'.ljust(unicodedata.east_asian_width(' '))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'str' object cannot be interpreted as an integer

The function posted in msg155361 looks like east_asian_width() is not enough to get the width in columns of a single character.
History
Date User Action Args
2012-03-19 12:59:06vstinnersetrecipients: + vstinner, lemburg, loewis, benjamin.peterson, ezio.melotti, eric.araujo, Arfrever, inigoserna, zeha, poq, Nicholas.Cole, tchrist
2012-03-19 12:59:06vstinnersetmessageid: <1332161946.76.0.987175844351.issue12568@psf.upfronthosting.co.za>
2012-03-19 12:59:06vstinnerlinkissue12568 messages
2012-03-19 12:59:05vstinnercreate